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(57) Abstract 



The invention relates to various methods for configuring configurable hardware blocks. The methods are especially characterized by 
generation of the configuration data used to configure the hardware blocks. The methods described for generating configuration data enable 
configuration data to be generated and allow hardware blocks to be configured easily, quickly and efficiently using said configuration data. 



(57) Zusammenfassung 

Es werden verschiedene Verfahren zur Konfigurierung von konfigurierbaren Hardware-Blocken beschrieben. Die Verfahren zeichneri 
sich insbesondere durch die Generierung der Konfigurationsdaten aus, unter Verwendung welcher die Hardwarer-Blocke konfiguriert 
werden. Durch die beschriebcnc Konfigurationsdaten-Erzeugung konnen sowohl die Konfigurationsdaten-Erzeugung selbst als auch die 
liardware-Block-Konfigurierung unter Verwendung dieser Konfigurationsdaten einfach, schnell und effizient durchgefuhrt werden. 
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Beschreibung 

Verfahren zum Konf igurieren eines konf igurierbaren Hardware- 
Blocks 

Die vorliegende Erfindung betrifft ein Verfahren gemafi dem 
Oberbegriff der PatentanspriAche 1 und 22, d.h. ein Verfahren 
zum Konf igurieren eines konf igurierbaren Hardware-Blocks. 

Ein derartiges Verfahren wird unter anderem benotigt, urn die 
sogenannte s-unit eines sogenannten >S<puters zu konf igurie- 
ren. Ein >S<puter ist eine programmgesteuerte Einheit, die 
insbesondere durch die Verwendung eines konf igurierbaren 
Hardware-Blocks in dem die Befehle abarbeitenden Teil in der 
Lage ist, mehr als einen Befehl pro Prozessortakt auszufuh- 
ren . 

Ein solcher >S<puter ist beispielsweise aus der EP 0 825 540. 
Al bekannt. 

Der grundlegende Aufbau eines >S<puters ist in Figur 11 ge- 
zeigt und wird nachfolgend unter Be zugnahme hierauf beschrie- 
ben . 

Der Vollstandigkeit halber sei bereits an dieser Stelle dar- 
auf hingewiesen, dafi. der >S<puter / insbesondere dessen die 
Befehle abarbeitende Teil nur teilweise (nur so weit es fur 
die vorliegend naher betrachteten konf igurierbaren Hardware- 
B16cke und deren Konf igurierung von Bedeutung ist) dar- 
gestellt und beschrieben ist. 

Der >S<puter gemafi Figur 11 umfafit eine Vordecodier-Einheit 
(predecode unit) 1, einen Instruktions-Puf f er (instruction 

buffer) 2, eine Decodier-, Umbenennungs- und Lade-Einheit 
(decode, rename & load unit) 3, die bereits erwahnte s-Para- 

digmen-Einheit (s-unit) 4, einen Daten-Cache (data cache) 5, 

und eine Speicher^Schnittstelle (memory interface) 6, wobei 
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die s-unit 4 aus einem Strukturprogrammier-Puf f er (programma- 
ble, structure buffer) 41, eiher Funktionseinheit mit pro- . 
grammierbarer Struktur (functional unit with programmable 
structure). 42, einem Integer/Adreilinstruktions- Puffer 
5 (integer/address instruction buffer) 43. undi einem Register- 
block (integer register file) 44 besteht. 

Die Besonderheit des >S<puters besteht insbesondere in dessen 
s-unit 4, genauer gesagt in der functional unit 42 derselben. 
. 10 Die functional unit 42 ist, eine konf igurierbare Hardware, die 
basierend auf vom >S<puter auszuf uhrenden Befehlen oder 
Bef ehlsf olgen dynamisch so konf igurierbar ist, dafi sie die 
durch die Befehle oder Bef ehlsf olgen vorgegebenen Aktionen 
bzw. Operationen ausfuhren kann. 

15 

Vom >S<puter auszufiihrende Instruktionen (genauer gesagt 
diese reprasentierende Code-Daten) gelangen aus einem nicht 
gezeigten Speicher uber das memory interface 6 in die pre- 
decode unit 1, wo. sie vordecodiert werden; dabei konnen zu 

20 den Code-Daten beispielsweise Inf ormationen hinzugefiigt wer- 
den, die die spatere Decodierung in der decode, rename & load 
unit 3 erleichtern. Die Code-Daten gelangen dann. iiber den 
instruction buffer 2 in die decode, rename & load unit 3, wo 
die Ausfuhrung der durch die Code-Daten reprasentierten 

25 Befehle vorbereitet wird. Diese Vorbereitung umfafit die 

Decodierung der Code-Daten, die Konf igurierung bzw. Struktu- 
rierung der functional unit 42, die Initialisierung bzw. 
Verwaltung des integer register file 44, und das Starten der 
wunschgemali konf igurierten functional unit 42. 

30 

Die Strukturierung bzw. Konf igurierung der functional unit 42 
erfolgt unter Verwendung von die gewunschte ^Configuration 
reprasentierenden Konf igurations-Daten, die von der decode, 
rename & load unit 3 in den programmable structure buffer 41 
35 geschrieben werden. Diese, die gewtinschte Konf iguration re- 
prasentierenden Konf igurations-Daten werden in der decode, 
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rename & load unit 3 kreiert; sie konnen aber auch schon in 
codierter Form in den Cdde-Daten enthalten sein. 

Die functional unit 42 ist dazu ausgelegt, Daten aus dem 
register file 4 4 und/oder dem data cache 5 auszulesen, die 
ausgelesenen, Daten arithmetisch und/oder lpgisch zu verarbei- 
ten, und das Ergebnis der Verarbeitung reprasentierende Daten 
in das register file 44 und/oder den data cache 5 einzu- 
schreiben. 

Bei geeigneter Initialisierung des register file 44 und bei 
geeigneter Konf igurierung der functional unit 42 hat der Be- 
trieb der functional unit - 42 die Ausftihrung der Opera tionfh 
zu Folge, die durch die Ausfiihrung der Befehle, auf der Basis 
welcher die Initialisierung des register file 44 und die Kon- 
f igurierung der functional unit 42 erfolgten, zu bewirken 
sind. 

Die Vornahme der durch die Ausfiihrung von Instruktionen zu 
bewirkenden Aktionen durch eine entsprechend konf igurierte 
Hardware (die functional unit 42) ist bekanntlich bedeutend 
schneller als die Ausfiihrung der Befehle in den "normalen." 
. Arithmetisch/Logischen Einheiten (ALUs) von herkommlichen 
progranungesteuerten Einheiten. Dies gilt in besonderem MaBe 
fiir den Fall, daB die Hardware (die functional unit 42) so 
konfiguriert ist, daJJ durch deren Betrieb ein Ergebnis er- -. 
zielbar ist, das der Ausfiihrung mehrerer auf einanderf olgender 
Befehle (eines mehrere Befehle umfassenden Makrobef ehls) ent- 
spricht . 

Beziiglich weiterer Einzelheiten zum Aufbau, der Funktion und 
der Wirkungsweise von >S<putern und der darin enthaltenen 
konf igurierbaren Hardware wird auf die vorstehend bereits 
erwahnte EP 0 825 54 0 Al verwiesen. 

Der Vollstandigkeit halber sei angemerkt, dafi nicht alle 
Aktionen, die durch die vom >S<puter auszuf iihrenden Befehle 
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zu bewirken sind, durch die functional unit 42 ausfuhrbar 
sind. Befehie wie insbesbndere ztir Programmablauf steuerung 
bzw. Kontrollf lufisteuerung dienende Befehie wie beispiels- 
weise Branch-, Jump-, No-Operation-, Wait- und Stop-Bef ehle 
5 werden in der Regel auf herk5mmliche Art und Weise ausgefuhrt 
• 'werden.- - 

Nichtsdestotrotz kann durch die Verwendung konf igurierbarer 
Hardware-Blocke wie der functional unit 42 im allgemeinen 
10 eine hohere Anzahl von durch auszuf uhrende Befehie zu bewir- 
kenden Aktionen pro Zeiteinheit ausgefiihrt werden als es mit 
herkominlichen programmgesteuerten Einheiten der Fall ist, 
also mehr als ein Befehl pro Prozessortakt abgearbeitet wer- 
den; 

15 

Voraussetzung ist natiirlich, daB die Hardware-Blocke schnell 
konfiguriert und effizient genutzt werden. 

Der vorliegenden Erfindung liegt daher die Aufgabe zugrunde, 
20 das Verfahren gemafl dem Oberbegriff des Patentanspruchs 1 

derart weiterzubilden, dafi die Hardware-Blocke fur beliebige 
Anwendungen schnell und einfach konf igurierbar und effizient 
nutzbar sind. 

25 Diese Aufgabe wird erf indungsgemafi durch die im kennzeichnen^ 
den Teil des Patentanspruchs 1 und durch die im kennzeichnen- 
den Teil des Patentanspruchs 22 beanspruchten Merkmale 
gelost. 

30 Demnach ist vorgesehen, 

■ - dafi die Hardware-Block-Konf igurierung unter Verwendung von 
Konf igurationsdaten erfolgt, die aus einer Umsetzung von 
Befehlen oder Bef ehlsfolgeh eines auszuf uhreriden Programmes 
35 resultieren, und dafi bei der Umsetzung der Befehie oder 
Bef ehlsfolgen die Schritte 
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- Ermittlung der zur Ausfuhrung eines jeweiligen Befehls 
benotigten Art von Teileinheit des konf igurierbaren 
Hardware-Blocks, 

- Auswahl einer noch nicht anderweitig belegteri Teileinheit 
der zuvor ermittelten Art, und - sofern eine solche Teil- 
einheit. gefunden werden konnte. 

- Konf igurieren von um die ausgewahlte Teileinheit. herum 
vorgesehenen konf igurierbaren Verbindungen 

ausgefuhrt werden (kennzeichnender Teil des Patentanspruchs 
1 ) bzw. 

- dafi die Hardware-Block-Konf igurierung unter Verwendung von 
Konf igurationsdaten erfolgt, die aus einef Umsetzung des 
Codes resultieren, der generiert wird, wenn eine Schaltung, 
die durch den konf igurierbaren. Hardware-Block realisiert 
werden soil, unter Verwendung einer Schaltungs- 
beschreibungssprache definiert wird (kennzeichnender Teil 
des Patentanspruchs 22). 

Durch eine derartige Vorgehensweise lassen sich zu konfigu- 
rierende Hardware-Blocke unter alien Umstanden mit minimalem 
Aufwand wunschgemafi konf igurieren. Die Konf iguration erfolgt 
dabei sehr schnell und nutzt die Komponenten des Hardware- 
Blocks optimal aus; so konf igurierte Hardware-Blocke lassen 
sich sehr effizient einsetzen. 

Vorteilhafte Weiterbildungen der Erfindung sind den Unter- 
anspriichen, der nachf olgenden Beschreibung und den Figuren 
ehtnehmbar. 

Die Erfindung wird nachf olgend anhand von Ausf uhrungsbeispie- 
len. unter Bezugnahme auf die Figuren naher erlautert. Es zei- 
gen 

Figuren 1A bis ID ein Beispiel filr einheitliche Befehis- 

Formate, die die umzusetzenden Befehle im betrach- 
teten Beispiel aufweisen sollten oder in die sie. 
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vor Beginn der Umsetzung vorzugsweise gebracht 
We r den, 

Figur 2 eine bei der hardwafemMigen Realisierun der Urn-. 
5 setzung vefweridete Look-Up-Table, 

Figuren 3A und 3B das Format der aus der Look-Up-Table gemafi 
Figur 2 ausgegebenen Daten, 

10 Figur 4 das Blockschaltbild . einer Schaltung zur Auswahl 

und Konf igurierung einer zur Ausfuhrung eines Be- 
fehls benotigten Teileinheit des . Hardware-Blocks, 

Figur 5 das Blockschaltbild einer Schaltung zur Festlegung 
15 der Daten- und/oder Signalquellen und der Daten- 

und/oder Signalziele fur die durch die Schaltung 
gemafi Figur 4 ausgewahlte Teileinheit, 

Figur 6 das Blockschaltbild einer Schaltung zur Handhabung 
20 von in den umzusetzenden Bef ehleri enthaltenen Kon- 

stanten, 

Figur 7 das Blockschaltbild einer Schaltung zur Durchfuh- 
rung des sogenannten Data Forwarding, 

25 - ••; 

Figur 8 einen sogenannten Cross-Bar-Switch zum Einschrei- 
ben der Konf igurations-Daten in einen temporaren 
Bitstrom, 

30 Figur 9 eine Anordnung ziim Einschleusen des temporaren 

Bitstroms in einen Hauptbitstrom, 

Figur 10 eine komplette Anordnung zum Umsetzen von Befehlen 
in Konf igurations-Daten zur wunschgemafien Konf igu- 
35 rierung. des Hardware-Blocks, 



Figur 11 



den prinzipiellen Aufbau eines >S<puters, und 
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Figur 12 den prinzipiellen Aufbau eines Hardware-Blocks der 
vorliegend naher betrachteten Art.. 

5 Ziir Erleichterung des Verstamdnisses wird zunachst der prin- 
zipielle Aufbau eines Hardware-Blocks, beschrieben, der durch 
die danach beschriebene Verfahren konfiguriert werden soil. 

Der prinzipielle. Aufbau eines solchen Hardware-Blocks ist in 
10 Figur 12 gezeigt. Der gezeigte Hardware-Block ist dazu aus- 

gelegt ist, abhangig von seiner Konf igurierung in einer 

Speichereinrichtung gespeicherte Daten auszulesen, . die aiis- 
: gelesenen Daten arithmetisch und/oder logisch zu yerarbeiten 

und das Ergebnis der Verarbeitung reprasentierende Daten in 
15 die Speichereinrichtung einzuschreiben; er ist beispielsweise 

als die functional unit 42 des >S<puters geimafi Figur 11 ein- 

setzbar . 

Die Speichereinrichtung, aus welcher der . konf igurierbare . 

20 Hardware-Block Daten ausliest und in welche der Hardware- 
Block Daten einschreibt, kann innerhalb oder aufierhalb des 
Hardware-Blocks vorgesehen sein; im vorliegend betrachteten 
Beispiel wird die Speichereinrichtung durch das register file 
44 des >S<puters gemafi Figur 11 gebildet. Der Hardware-Block 

25 ist ein asynchrones Schaltnetz zwischen den Aus- und Eingan- 
gen der Speichereinrichtung; die Bestandteile des Hardware- 
Blocks sind asynchron miteinander gekoppelt . 

Die Speichereinrichtung ist vorzugsweise von aufierhalb des 
30 Hardware-Blocks vor der inbetriebnahme desselben initiali- 
sierbar; denkbar ware auch, dafi der Hardware-Block die 
Initialisierung der Speichereinrichtung selbst veranlafit oder 
durchfuhrt. 

35 Der in der Figur 12 gezeigte Hardware-Block weist. eine oder 
mehrere arithmetische Einheiten AU1, AU2, eine oder mehrere 
Vergleichs-Einheiten CU, einen oder mehrere Multiplexer eines 
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ersten Typs MUXA1, MUXA2, MUXA3, einen oder mehrere Multi- 
plexer eines zweiten Typs MUXB, und einen oder mehrere De- 
multiplexer DEMUX auf . 

5 Die arithmetischen Einheiten AU1, AU2 weisen im betrachteteri 
Beispiel zwei Eingangsanschlusse, einen Ausgangsanschluil und 
einen Steueranschlufi auf. Den arithmetischen Einheiten AU1, 
AU2 obliegt es, die iiber deren Eingangsanschlusse eingegebe- 
nen Eingangssignale arithmetisch und/oder logisch zu verar- 

10 beiten. Die Operationen, die durch die arithmetischen Ein- 
heiten AU1, AU2 ausfiihrbar sind, konnen f est vorgegeben oder 
individueli -einstellbar ( konf igur i erbar ) sein; sie umfasseh 
insbesondere arithmetische Operationen wie Addition, Subtratk 
tion, Multiplikation, Division etc., logische Verknttpf ungen 

15 wie UND-Verkmipf ungen, ODER-Verkniipf ungen, Invertierung, 
Komplementbildung etc., arithmetische und logische Shift- 
Operationen, und Datentransf ers (Durchschaltung eines der 
eingegebenen Signale zum Ausgangsanschluii) . Die arithmeti- 
schen Einheiten AU1, AU2 sind nicht mit den Arithmetisch/- 

20 Logischen Einheiten (ALUs) herkommlicher programmgesteuerter 
Einheiten wie Mikroprozessoren, Mikrocontrollern etc. gleich 
zusetzen; die von ihnen ausfiihrbar en Operationen sind be^ 
grenzt, so daB der Aufbau der arithmetischen Einheiten AU1, 
AU2 vergleichsweise einfach bleiben kann. Ober die Steuer- 

25 anschliisse der arithmetischen Einheiten Auri, AU2 ist f est- 
legbar, ob die betreffende arithmetische Einheit die Opera- 
tion, zu deren Ausftihrung sie vorgesehen ist, ausfuhrt oder 
hicht. Dies ermoglicht die praktische Umsetzung von Befehlen 
deren Ausfuhrung vom Vorliegen einer bestimmten Bediiigung ab 

30 hangt. Die Bedingung kann beispielsweise der Zustand eines 
bestimmten Flags sein: ist das Flag gesetzt, wird die der 
betreffenden arithmetischen Einheit obliegende Aufgabe (bei- 
spielsweise eine Addition) ausgefuhrt, andernfalls nicht 
(oder umgekehrt) • Derartige, nachfolgend als "konditionierte 

35 Bef ehle" bezeichnete Befehle ermoglichen es, die schwer hand 
habbaren bedingten Sprungbef ehle zu eliminieren; sie werden 
spater noch genauer beschrieben. 
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Die Vergl£ichs-Einheit CU weist im betrachteten Beispiel- zwei 
Eingangsanschltisse . und einen . AusgangsanschluJi auf.- Der Ver- 
gleichs-Einheit CU obliegt eS, die an deren Eihgangsanschlus- 
5 sen anl i egenderi S igriale oder Daten. Vergleichsoperationen zu 
unter Ziehen . : Die Operationen, die durch die Vergleichs-. 
Einheit CU ausftihrbar sind, konnen fest vorgegeben oder 
individuell einstellbar (konf igurierbar) sein; sie umfassen 
beispielsweise Grofier-, Grofier/Gleich-, Kleiner-, Kleiner/- 

10 Gieich-,. Gleich-, und Ungleich-Vergleiche und Oberpriif ungen 
auf wahr (TRUE) und unwahr (FALSE) . Der Ausgangsanschlufi der 
Vergleichs-Einheit CU ist tiber deh riachfblgend noch genauer 
beschriebenen Demultiplexer DEMUX mi t den Steueranschliissen 
der arithmetischen Einheiten AU1, AU2 verbunden. Vom Ergebnis 

15 der in der Vergleichs-Einheit CU ausgefiihrten Operation hangt 
es also ab, ob die arithmetischen Einheiten AU1, AU2 die 
Operation> zu deren Ausfiihrung sie vorgesehen sind, ausfuhren 
oder nicht. 

20 Die Multiplexer des ersten Typs MUXA1 , MUXA2 , MUXA3, der 
Multiplexer des zweiten Typs MUXB, und- der Demultiplexer 
DEMUX dienen zur Auswahl der Daten- und/oder Signalquellen 
und der Daten- und/oder Signalziele. Genauer gesagt dienen 

25 - der Multiplexer MUXA1 zur Auswahl der Quell en der den Ein- 
gangsanschltissen der arithmetischen Einheit AU1 zugefiihrten 
Daten und/oder Signale (mogliche Daten- und/oder Signal- 
quellen sind im betrachteten Beispiel das register file 44 
und andere arithmetische Einheiten) > 

; 30 

- - der Multiplexer MUXA2 zur Auswahl der Quellen der deri 

Eingangsanschltissen der arithmetischen Einheit AU2 zuge- 
fiihrten Daten und/oder Signale {mogliche Daten- und/oder 
Signalquellen sind im betrachteten Beispiel das register 

35 file 44 und andere arithmetische Einheiten), 
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- der Multiplexer MUXA3 zur Auswahl der Quellen der den 
Eingangsanschlus sen der Vergleichs-Einheit CU zugeftihrten 

. Daten und/oder Signale (mogliche Daten- und/oder Signal- 
•quellen sind im betr'acKteten Beispiel das register file 44 
5 und die; arithmetischen. Einheiten) , . 

- der. Multiplexer MUXB zur Auswahl der Quellen der dem 
register file zugefiihrteri Daten und/oder Signale (mogliche 
Daten- und/oder Signalquellen sind im betrachteten Beispiel 

10 die arithmetischen Einheiten und/oder das register file 
selbst) , 

- der Demultiplexer DEMUX zur Auswahl des oder der Ziele fur 
die von der Vergleichs-Einheit CU ausgegebenen Daten 

15 und/oder Signale (mogliche Daten- und/oder Signalziele sind 
im betrachteten Beispiel die arithmetischen Einheiten). 

Die Multiplexer des ersten Typs weisen mehrere Eingangs- 
anschlusse und zwei Ausgangsanschlusse auf , die Multiplexer 
20 des zweiten Typs mehrere Eingangsanschlusse und. einen Aus- 
gangsanschluB, und der Demultiplexer einen EingangsanschluJi 
und mehrere Ausgangsanschlusse, 

Die Multiplexer und der Demultiplexer weisen in der Figur 12 
25 nicht gezeigte Steueranschlusse auf / uber welche einstellbar 
1st, welche Eingangsdaten und/oder -signale auf welche Aus- 
gangsanschlusse durchgeschaltet werdeh. Die Anzahl der 
Steueranschliisse hangt von der erf orderlichen Anzahl der 
verschiedenen Zuordnungs-Kombinationen ab; bei 32 Eingangs- 
30 anschlQssen und zwei Ausgangsanschliissen sind beispielsweise 
10 Steueranschlusse erforderlich, urn an beliebigen Eingangs- 
anschlussen anliegende Signale und/oder Daten auf beliebig^ 
Ausgangsanschliisse durchschalten zu konnen. Im Fall des Ein- 
satzes des Hardware-Blocks als. functional unit 42 im >S<puter 
35 gemaiS Figur 11 sind die: Steuersignalanschltisse vorzugsweise 
mit dem programmable structure buffer. 41 verbunden, so da6 
die in diesen eingeschriebenen Konf igurations-Daten im we- 



WO 00/17771 



PCT/DE99/02878 



sentlichen unmittelbar zur Multiplexer-Ansteuerung verwendbar 
sind. Die im programmable structure buffer 41 gespeicherten 
Konf igurations-Daten umfassen vorzugsweise auch die Konf igu- 
rations-Daten zur Festlegung der jeweiligen Funktibn der 
: 5 arithmetisGlieh Einheiten AU1, AU2 und der. Vergle.ichs-Eiriheit 
CU. . ■ . : . . ;•■ , ■ • ... 

Durch die arithmetischen Einheiten AU1, AU2, die Vergleichs- 
Einheit CU, die Multiplexer des ersten Typs MUXA1, MUXA2, 

10 . MUXA3, den Multiplexer des zweiteri Typs MUXB, und den De- 
multiplexer DEMUX wird der Hardware-Block in die Lage ver- 
setzt/ in einer Speichereinrichtung (im register file 44) 
gespeicherte Da ten auszulesen, die ausgelesenen Daten arith- 
metisch und/oder logisch zu verarbeiten und das Ergebnis der 

15 Verarbeitung reprasentierende Daten in die Speichereinrich- 
tung (das register file 44 ) einzuschreiben . 

Der in Figur 12 gezeigte und unter Bezugnahme darauf 
beschriebene Hardware-Block ist nur zur Erlauterung des 

20 grundlegenden Aufbaus gedacht . In der Praxis werden die 
arithmetische Einheiten, die Vergleichs-Einheiten, die 
Multiplexer, und die Demultiplexer in einer deutlich groBeren 
Anzahl vorgesehen werden als es beim Beispiel gemafi Figur 12 
der Fall ist. Der Hardware-Block 1st vorzugsweise so 

25 dimensioniert, dafi normal erweise samtliche Operationen, die 
von einem spater noch naher beschriebenen, sogenannten 
Hyperblock zu bewirken sind, auf ein Mai in ihn 
einprogrammierbar sind. 

30 Die im Hardware-Block vorgesehenen Daten- und/oder Signal- 

pfade konnen durch einzelne Leitungen oder durch Busse gebil- 
det werden, wobei es sich als vorteilhaft erweisen kann, wenn 
in den einzelnen Teileinheiten des Hardware-Blocks oder im 
Bus-System konf igurierbar ist, wie viele und/oder welche Bus- 

35 leitungen zu berucksichtigen sind. 
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Die Konf igurierung eines Hardware-Blocks nach Art der Figur 
12 kann basierend auf Befehlen oder Bef ehlsf olgen erf olgen. 
Setzt man Befehle oder Bef ehlsf olgen in entsprechende Hard- 
ware -Block- St ruktur en urn, so ist der so konf igurierte Hard- 
5 ware-Block als Abl auf einheit fur sequentielle Bef ehlsf olgen 
nutzbar . Diese Form der Hardware-Block-Konf igurierung. wird 
nachfplgend auch als struktur-prozedurale Programmierung 
bezeichnet . 

10 Ausgangspunkt fur die struktur-prozedurale Programmierung 

kann ein in einer Hochsprache wie beispielsweise C, C++ etc. 
geschriebehes Programm sein. Dieses Programm wird durch einen 
Compiler ubersetzt; und der dabei erhaltene Code wird 
(vorzugsweise hyperblock-weise) in Strukturinf ormationen 

15 umgesetzt, basierend auf welcher der zu konf igurierende Hard- 
ware-Block konf igurierbar ist. Was unter einem Hyperblock zu 
verstehen ist, wird spater noch genauer beschrieben werden. 

Ausgangspunkt fur die struktur-prozedurale Programmierung 
20 kann selbstverstandlich auch ein in Assembler geschriebenes 
oder sohstiges Programm sein. Die Art und Weise der Pro- 
grammierung (funktional, imperativ, objekt-orientiert, ...')■" 
ist ebenfalls keinen Eihschrankungen unterworfen. 

25 Es erweist sich als vorteilhaf t wen'n der in die Struktur- 
inf ormation umzusetzende Code, also die durch den Compiler 
oder auf andere Art und Weise erzeugten Maschinenbef ehle nur 
bestimmte Maschinenbef ehl-Typen, namlich unkonditionierte Be- 
fehle, konditionierte Befehle, Predicate-Bef ehle, und Loop- 

30 Befehle umfassen. Dann lassen sich in der Regel besonders 
lange (besonders viele Befehle enthaltende) Bef ehls-Blocke 
mi t nur einem Eintrittspunkt und nur einem Austrittspunkt . 
bilden. Die Generierbarkeit von moglichst langen Befehls- 
Blocken mit nur einem Eintrittspunkt und nur einem Austritts- 

35 punkt ist sehr bedeutsam, weil sich Befehle, die ein- und dem 
selbien Bef ehls-Blbck angehoren, und zwar nur solche Befehle, 
als eine Einheit (als eine sich aus mehreren Befehlen zu- 



WO 00/17771 



PCT/DE99/02878 



13 

sammensetzende Makroinstruktion) behandeln lasseh, die in 
eine gemeinsame Hardware-Blbck-Struktur umgesetzt und auf eirt 
Mai ausgefuhrt werden kann. Legt man der Konf igurierung. eines 
Hardware-Blocks jewel Is geiiau eine sblche Einheit zugrunde " 
5 (und 1st der Hardware-BldGk. grofi genug, um. so konf iguriert 
werden zu konnen) > so lafit sich die Anzahl der zur. Abarbei- 
tung eines Programms erf orderlichen Umstrukturierungeri bzw. 
Umkonf igurierungen des Hardware-Blocks auf ein Minimum redu- 
zieren. Die Bef ehls-Blocke, deren Generierung derzeit favori- 
10 siert.wird, und deren Bildung durch die vorstehend genannten 
Befehlsgruppen auch moglich ist, sind die vorstehend bereits 
erwahnten Hyperblocke. 

Hyperblocke zeichnen sich insbesondere dadurch aus, dafi be- 
15 dingte Sprungbef ehle unter Anwendung der nachfolgend noch 

naher beschriebenen sogenannten if-Konversion eliminiert wer- 
den 

Beziigiich weiterer Einzelheiten zu den Hyperblocken, anderen 
.20 Bef ehls-Blocken und damit in Zusammenhang stehenden Themen 
wird auf 

- Wen-Mei W. Hwu et al .: "Compiler Technology for Future 
Microprocessors", Invited Paper in Proceedings of the IEEE, 

25 Vol. 83 (12), Dezember 1995, Special Issue on Micro- 
processors, Seiten 1625 bis 1640, 

- Henk Neefs, Jan van Campenhout: "A Microarchitecture for a 
Fixed Length Block Structured Instruction Set Architec- 

30 ture", Proceedings of the Eighth IASTED International. 
Conference on Parallel and Distributed Computing and 
Systems, Seiten 38 bis 42, IASTED/ACTA Press, 1996, und 

- Richard H. Littin, J. A. David McWha, Murray W. Pearson, 
35 John G. Cleary: "Block. Based Execution and Task Level 

Parallelism", in: John Morris (Ed.), "Computer Architecture 
98", Proceedings of the 3 rd Australasian Computer Architec- 
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ture Conference, ACAC98, Perth, 2-3 February 1998, Austra- 
lian Computer Science Communications, Vol, 20, No. 4, Sei- 
ten 57 bis 66, Springer, Singapore, 

5 ; verwiesen. "' 

Die vorstehend erwahnten unkonditionierten Befehle sind Be- 
fehle zur bedingungslosen. Bearbeitung von Daten einschliefi-. 
lich der Kopie von Daten von einem Speicherbereich in einen 

10 anderen (von einem Register in ein aiideres) . Diese Befehle 
werden im folgenden als normale Befehle bezeichnet. Sie urn- 
fassen a r i thine ti s che und logische Verkntipf ungen zwischen 
Daten zu neueh Werten und die sogenannten Move-Bef ehle zur 
Kopie von Registerinhalten. Das allgemeine Format dieser Be- 

15 fehle lautet: <Mnemonic> <Ziel-Register>, <Quellen-Register 
1>, <Quellen-Register 2> v Zur Durchftihrung der durch einen 
solchen Bef ehl spezif izierten Operation wird normalerweise 
eine arithmetische Einheit des Hardware-Blocks benotigt. 

20 Die konditionierten Befehle sind Befehle zur Bearbeitung von 
Daten bei Vorliegen einer bestimmten Bedingung (Konditibn) • 
Die durch diese Befehle auszuf uhrenden Aktionen entsprechen 
den durch die normalen Bef ehle ausfuhrbaren Aktionen, wobei 
die Ausftihrung der betreffenden Aktionen jedoch von einer 

25 vorbestiirauten Bedingung abhangt . 1st die Bedingung erf til it , 
wird die durch den Befehl spezif izierte Aktion ausgefUhrt, 
anderenfalls wird nichts ausgefiihrt (der betreffende Befehl 
wirkt dann wie ein NOP-Befehl) . Diese Befehle werden im fol- 
genden als bedingte Befehle bezeichnet. Das allgemeine Format 

30 dieser Befehle lautet: <Mnemonic>p <Ziel-Register>, <Quelleh- 
Register 1>, <Quellen-Register 2> <p-Flag>, wobei durch das 
"p" am Ende des Mnemonic die Abhangigkeit der Bef ehlsausf uh- 
rurig von einer Bedingung signalisiert wird, und wobei die 
Bedingung durch einen bestimmten Zustand eines bestimmten 

35 Flags (des "p-Flag" ) def iniert wird. Zur Durchftihrung der 
durch einen solchen Befehl spezif izierten Operation wird 
normalerweise eine arithmetische Einheit des Hardware-Blocks 
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benotigt; zur Oberprtifung der Bedingung wird eine Vergleichs- 
Eiiiheit benotigt, deren Ausgang mit dem Steuereingang der 
arithmetischen Einheit verbindbar ist. 

5' Die Predicate-Befehle sind Befehle zur Fes tleg.ung des Zustan- 
des des in den bedingten Befehlen verwendeten Bedingungs- 
Flags (des p-Flags) . Die Festlegung erfolgt dabei wahrend des 
Programmablauf s basierend auf einem Vergieich von.zwei Daten. 
Diese Befehle werden im folgenden als pxx-Befehle bezeichnet. 
10 Das allgemeine Format dieser Befehle lautet: pxx<Quellen- 
Register 1>, <Quellen-Register 2>, <p-Flag>, wobei xx die 
durchzufuhrende Vergleichsoperation spezif iziert. und durch gt . 
(grofier als), ge (grofier oder gleich) , eg (gleich) , ne 
(ungleich) , le (kleiner oder gleich) oder It (kleiner als) zu 
15 ersetzen ist. Die pxx-Befehle sind mit den ublichen Branch- 
Bef ehlen. vergleichbar und . dienen zum Ersatz derselben durch 
die Anwendung der sogenannten if-Konversion (siehe hierzu den 
vorstehend bereits erwahnten Aufsatz von Wen-Mei W . Hwu et 
' al. ) . 

20 

Die Loop-Bef ehle sind zur Schleif enwiederholung dienende 
Befehle am Ende eines Hyperblocks. Sie veranlassen einen 
RiAcksprung an den Anfang des betreffenden Hyperblocks, falls 
eine im Befehl spezif izierte Bedingung erf ullt ist; sie kon- 
25 hen die Geherierung eines READY-Signals veranlassen, wenn die 
Bedingung nicht mehr erftillt ist. Die Bedingung ist durch ein 
bestiromtes Ergebnis einer Vergleichsoperation definiert. Das 
. allgemeine Format dieser Befehle lautet: loopxx <Quellen- 
Register 1>, <Quellen-Register 2>, wobei xx die durchzu- 
30 ftihrend^ Vergleichsoperation spezif iziert . " 

Wie aus den Formaten der genannten Befehlstypen ersichtlich 
ist, werden als Daten- und/ oder Signalquellen und Daten- 
und/oder Signalziele jeweils Register verwendet. Dies erweist 
35 sich bei Verwendung von Hardware-Blocken nach Art der Figur 
12 als besonders vorteilhaft, well auf die Registeir (das 
register file 44) besonders ef f izient zugegrif f en werden. 
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kann. Prinzipiell konnten aber auch Refehle zugelassen wer- 
den, deren Daten- und/oder. - Signal quel l.en und. Daten- und/oder > 
Signalziele keine Register sind. 

5 Viele Programme oder wenigstens groBe Telle von -die-sen- konnen 
. unter ausschlieBlicher Verwendung der yorstehend. erlauterten 
Befehls-Typen geschrieben oder in solche Programme uber set zt 
werden und mithin vollstandig in einen Hardware-Block der in 
der Figur 12 gezeigten Art zur Ausftlhrung gebracht werden. 
10 Die Verwendung derartiger Hardware-Blocke in programm- 

gesteuerten Einheiten kann deren Leistungsf ahigkeit daher 
erheblich steigern. Hardware-Blocke der in der Figur 12 ge- 
zeigten Art konnen jedoch auch aufierhalb programmgesteuerter 
Einheiten als eigenstandige Einrichtungen zum Einsatz kommen 
15 und dann ebenfalls basierend auf Befehlen oder Bef ehlsstromen 
konfiguriert werden. 

Im folgenden wird nunmehr die Konf igurierung eines Hardware- 
Blocks beschrieben, durch welche dieser durch Befehle oder 
20 Bef ehlsfolgen vorgegebene arithmetische und/oder logische 
Operationen oder Operations folgen ausfuhreh kann. 

Der Hardware-Block, genauer gesagt dessen Teileinheiten 
(arithmetische Einheiten, Vergleichs-Einheiten, Multiplexer, 
25 Demultiplexer . . . ) und die Verbindungen zwischen den Teil- 

einheiten werden im betrachteten Beispiel durch die ge- 

wunschte Konf iguration reprasentierenden Konf igurations-Daten 
(Konfigurations-Bits) konfiguriert. Dementsprechend ist es 

die Aufgabe des nachfolgend beschrlebenen Konf igurat ions- 
30 Verfahrens, die Konf igurations-Daten bzw. einen diese ent- 

haltenden Bitstrom. basierend auf den der Hardware-Block- 

Konf iguration zugrundezulegenden Befehlen oder Bef ehlsfolgen 

zu generieren oder zu variieren. 

35 Im betrachteten Beispiel wird dayon ausgegangen, dafi aus-. 

schlieBlich die vorstehend genannten Typen yon Befehlen, d.h. 
normale Befehle, bedlngte Befehle, pxx-Befehle und loopxx- 
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Befehle umgesetzt werden;. andere Befehle mussen anderweitig 
ausgefuhrt Werderi, beispielsweise durch die AusfUhrungs-' 
einheit einer herkommlichen programmgesteuerten Einheit . 

5 Fur die Umsetzuhg der umsetzbaren Befehle in entsprechende 

Hardware--Block-Strukturen kann es sich als vorteilhaft erwei- 
sen, wenn die Befehle von Haus aus ein in den Figuren 1A 
(normale Befehle) , IB (bedingte Befehle) , 1C (pxx-Bef ehle) ,- 
und ID (loopxx-Bef ehle) beispielhaft veranschaulichtes ein- 
.10 heitliches Format aufweisen oder durch einen Decodierer in 
ein solches Format gebracht werden. 

Irisbesohdere wenn die Teileinheiten des Hardware-Blocks 
konf igurierbar sind, werden diesen (physikalischen) Teil- 

15 einheiten logische bzw. virtuelle Einheiten zugeordnet, wobei 
die virtuellen Einheiten die verschiedenen Funktionen der 
physikalischen Teileinheiten angeben. Der physikalischen 
Teileinheit "erste arithmetische . Einheit AU1" konnen - sofern 
diese konf igurierbar ist - beispielsweise die virtuellen Ein- 

2 0 heiten Addierer, Subtrahierer etc. zugeordnet sein. Eine 

virtuelle Einheit ist genau einer physikalischen Teileinheit 
zugeordnet, aber einer physikalischen Teileinheit konnen 
mehrere virtuelle Einheiten zugeordnet sein. Samtliche vir- 
tuellen Einheiten werden vorzugsweise in einer Tabelle oder 

25 Liste verwaltet . Die jeweiligen Eintrage enthalten neben 

Informationen zu den virtuellen Einheiten selbst auch Infor- 
mation dartiber, welcher physikalischen Teileinheit die jewei- 
' ligen virtuellen Einheiten zugeordnet . sind, iiber welche 
Konf igurations-Bits und wie diese physikalische Teileinheit 

30 gegebenenf alls konfiguriert werden muB, vim ihr die durch die 
virtuelle Einheit reprasentierte Funktion zu verleihen. 

Vorzugsweise wird ein kompletter Hyperblock in eine Hardware- 
Block-Struktur umgesetzt. 

35 

: Die Umsetzung eines B.efehls in eine Hardware-Block-Struktu- 
rierungsinformationen erfolgt im wesentlichen in drei Phasen. 
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In der ersten Phase wird zunachst ermittelt, welcher Typ von 
viftueller Einheit (Addierer, Subtrahierer, Multiplizierer 
.."..) zur Ausf iihrurig der betref f enderi Instruction benotigt 
5 ' wird, und ob eine sol che vi rtue 11 e Eiriheit nocK verfugbar 
ist . 1st noch eine .virtuelle Einheit des benotigt en Typs 
frei, so wird diese oder eine von diesen zur Ausfuhrung der 
betref fenden Instruktion ausgewahlt. Sodann erfolgen die Kon- 
figuration oder deren Vorbereitung und eine Reservierung der 

10.. der ausgewahlt en virtuellen Einheit zugeordneten physikali- 
schen Teileinheit- Zur Konf iguration werden einfach die der 
betref feriden physikalischen Teileinheit zugeordneten Konf igu- 
rations-Bits gesetzt oder zuruckgesetzt ; dies bereitet keine 
Schwierigkeiten, denn die Inf ormationen, welcher physikali- 

15 schen Teileinheit die ausgewahlte virtuelle Einheit zugeord- 
net ist, uber welche Konf igurations-Bits und wie diese physi- 
kalische Teileinheit gegebenenf alls zu konf igurieren ist , 
werden ja zusammen mit der virtuellen Einheit verwaltet. Die 
Reservierung der der ausgewahlten virtuellen Einheit zugeord- 

20 ne.ten physikalischen Teileinheit ist notwendig, urn zu verhin- 
dern, dafi die betreffende physikalische Teileinheit mehrfach 
verwendet werden kann. Im betrachteten Beispiel wird dies 
dadurch bewerkstelligt, dafi nach jeder Vergabe einer physi- 
kalischen Teileinheit fur einen bestimmten Zweck samtliche 

25 virtuellen Einheiten, die der betref fenden physikalischen 
Teileinheit zugeordnet sind, gesperrt werden. 

Bei pxx-Bef ehlen kann es je nach dem Aufbau des Hardware- 
Blocks erforderlich sein, abhangig vom p-Flag eine ganz be- 
30 stimmte physikalische Teileinheit (Vergleichs-Einheit) aus- 
zuwahlen. 

Bei bedingtzen Bef ehlen wirkt sich das p-Flag nur dann auf die 
Auswahl der virtuellen/physikalischen Einheit (en) aus, wenn 
35 bestimmte Instruktionen nur mit bestimmten Flags moglich 
sind, also keine vollstandige Orthogonalitat in dem Teil- 
befehlssatz fur bedingte Befehle vorhanden ist. 
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In der zweiten Phase der Hardware-Block-Konf igurierung werden 
die den. ausgewahlten physikalischen Teileinheiten vor- 
und/oder nachgeschalteten Multiplexer konf iguriert, um die 
5 Daten- und/oder Signalquellen und die Daten- und/oder Signal-' 
ziele entsprechend den Festlegungen in den umzusetzenden 
Instruktionen einzustellen. Die Multiplexer und das Format 
der umzusetzenden Instruktionen sind im Idealfall so anein- 
ander angepaiit, dafi die die Daten- und/oder Signalquellen und 
10 : die die Daten- und/oder Signalziele festlegenden Teile der 

Instruktionen unverandert als die die Multiplexer konfigurie- 
r.enden Konf igurations-Bits ubernommen werden konnen. 1st : dies 

- aus welchem Grund auch immer - nicht moglich, konneh die 
die Multiplexer konf igurierenden Konf igurations-Bits bei- 

1.5 spielsweise einer Tabelle entnommen werden,. in welcher die 

Zuordnung zwischen den die Daten- und/oder Signalquellen und 
die Daten- und/oder Signalziele festlegenden Teilen der 
Instruktionen und den: die Multiplexer konf igurierenden Kon- 
f igurations-Bits gespeichert ist. Die Konf igurierung, die . 

20 erforderlich ist, urn eine Verbindung zu einer bestimmten 
Daten- und/oder Signalquelle und/oder zu einem bestimmten 
Daten- und/oder Signalziel herzustellen, ist vcr zugsweise fur 
' alle.. Multiplexer gleich. 

25 Eine gesonderte Behandlung ist notwendig, Wenn die der aus- 
zufuhrenden Operation zugrundezulegenden Paten zumindest 
teilweise aus einer im Instruktions-Code enthaltenen Kon- 
stanten bestehen. Dann mufl 

- ein freies (Konstanten-) Register gesucht werden, 

30 - dieses Register als Daten- und/oder Signalquelle verwendet 
werden, und 

- die im Instruktions;-Code enthaltene Konstante vor der 
Inbetriebnahme des UCB in das ausgewahlte Register ein- 
geschrieben werden. 

35 

Im betrachteten Beispiel wird vorab OberprUft/ ob die be- 
treffende Konstante schon in einem (Konstanten-) Register 
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gespeichert ist. Ergibt sich dabei, dafi bereits ein die Kon- 
stahte enthaltendes (Konstanten-) Register existiert, so. wird 
dieses schon existierende (Konstanten-) Register als Daten- 
und/oder Signalquelle verwendet . 
" : '5 ..: . " - - ■ :•• - ; -;• .y. • ' .. ; - : • 

Zu; beachten ist ferner, dafi die umzusetzenden Instruktionen 
unterschiedlich viele Daten-. und/oder Signalquellen und 
Daten- und/oder Signalziele aufweisen und/oder von Bedingun- 
gen abhangen und insofern eine Sonderbehandlung der einzelnen 
...10. Instruktionen erforderlich ist. 

Als Daten^ und/oder Sigrialziel verwendete Register werden 
. iibrigens als belegt markiert, da innerhalb eines Hyperblocks 
keine Zweitbelegung zulassig ist und durch ein sogenanntes 
15 (Runtime) Register Renaming, einer aus superskalaren Archi- 
tekturen bekannten Technologies verhindert werden mufi. 

Nach dieser (flir alle Befehle gemeinsamen) zweiten Phase wer- 
den fur einzelne Befehlstypen spezielle Teilschritte einge- 
20 fugt, die sich aus den jeweiligen Besonderheiten ergeben. 

Unter anderem mufi. bei. bedingten Befehlen die das Vorliegen 
der. Bedingung iiberpriifende Vergleichs-Einheit ermittelt wer- 
den und deren Ausgangssignal tlber den zugehorigen Demulti- 
25 plexer auf die die Operation ausfuhrende arithmetische 

Einheit geschaltet werden. Ferner ist zu beriicksichtigen, 
welcher Art die Bedingung ist. 

Bei bedingten Mqve-Bef ehlen ist zusatzlich dafiir Sorge zu 
30 tragen, dafi der Inhalt des Zielregisters bei Nicht-Ausf tthrung 
des Befehls nicht veraridert wird. 

Nach der zweiten Phase der Hardware-Block-Konf igurierung 
konnte diese beendet und der Hardware-Block gestartet werden. 
35 Dies geschieht vprzugsweise jedoch erst nach der Ausfuhrung 
der nachfolgend beschriebenen dritten Phase. 
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In dieser dritten Phase der Hardware-Block-Konf igurierung 
wird eiii sogenanntes data forwarding realisiert. Dabei werden 
als Daten- und/oder Signalquellen nicht stur die in den In- 
s t ru k t i onen angegebeneh Daten- und/oder Si gna 1 que lien verwen- 
5 ;det, ' sonderh nach Moglichkeit die physikaiische Teileinheit, . 
die die betref fende Daten- und/oder Signalquelle innerhalb 
des jeweiligen Hyperblocks zuvorzu beschreiben hatte. Dies 
erweist sich in. zweifacher Hinsicht als vorteilhaf t : einer- 
seits, weil eventuell weniger Register benotigt werden (wenn 

10 die in der Iristruktion angegebene Daten- und/oder Signal- 
quelle nicht als solche verwendet wird, mufi sie auch nicht 
beschrieben werden und kann gegebenenf alls ganz weggelassen 
werden) , und andererseits, weil die benotigten Daten bei Ab- 
holung von der diese erzeugenden Teileinheit (beispielsweise 

15 einer arithmetischen Einheit) fruher verfugbar sind als wenn 
sie zuerst in ein Register geschrieben . und von dort abgeholt. 
werden mussen. Das data forwarding kann bei alien Befehlen 
zur Anwendung kommen und erweist sich im Durchschnitt als 
enormer Vorteil. 

20 

Das soeben kurz in Worten beschriebene Verfahren lafit sich 
auch durch dessen sof twaremaiiige und dessen hardwaremaBige 
Realisierungsmoglichkeiten und in mathematischer Notation 
verahschaulichen 

Zunachst soil eine sbf twaremaBige Realisierung in einer C++- 
ahnlichen Darstellung beschrieben werden. Im betrachteten 
Beispiel erfolgt die Verwaltung der Inf ormationen zu den 
Hardware-Block-Konf igurationsdaten durch Klassen. 

. 30 

Die Klasse ftir eine virtuelle Einheit wird im betrachteten 
Beispiel f olgendermafien definiert: 

class clVirtualUnit { 
35 private: unsigned int uiPhysicalPartNumber; 

unsigned int uiMnemonicType; 
BOOL blsConf igurable; 
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unsigned int uiConfBits; 
unsigned int uiCon f Bits Index; 
BOOL bTwoSour eeRegs ; 

unsigned int uiSrcMultiplexNumber [2] ; 

unsigned int ui S r cMu ltipl ex Index [ 2 ] ; 

BOOL bDestinationReg; 

unsigned int uiDestMultiplexNumber; 

unsigned int uiDestMultiplexIndex; 

BOOL blsUsed; 

BOOL bSecondPIsiised; 

BOOL blsConstantRegister; 

unsigned int uiConst ant Index; 

unsigned int uiCdnstantValue; . 

unsigned int uiGetPartNumber ( void.);", 
unsigned int uiGetMnemonicType ( void ) ; 
BOOL blsUnitConf igurable ( void ); 
unsigned int uiGetConfBits ( void ) ; 
unsigned int uiGetConfBitsIndex ( void ) ; 
BOOL bHasTwoSourceRegs ( void ); 
unsigned int uiGetSrcMultiplexNumber 

( unsigned int ) ; 
unsigned int uiGetSrcMultiplexIndex 

( unsigned int ) ; 
BOOL bHasDestinationReg ( void ) ; 
unsigned int uiGetDestMultiplexNumber ( void) 
unsigned int uiGetDestMultiplexIndex ( void ); 
void vFreePart ( void ); 
BOOL bMarkUsedPart ( void ) ; 
BOOL bMar JcSecondUsedFlag ( void ) ; 
BOOL bGetIsUsed( void ); 
BOOL bGetIsUsedSecondFlag( void ); 
BOOL blsConstantRegister (void ); 
BOOL bSetConstantValue ( void ) ; 
unsigned int uiGetConstantValue ( void ); 
unsigned int uiGetConstantlndex ( void ) ; ^ 
} 
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Die in der Klasse enthaltenen Daten undMethoden dienen zur 
Modellierung ein<er Mikroarchitektur . 

Von den Daten bedeuteii : 



uiPhysicalPartNumber : Diese Variable enthalt eine eindeutige 
Nummer fur die physikalische Teileinheit innerhalb des 
10. ... Hardware-Blocks. 

uiMnemonicType: Diese Variable enthalt in codierter. Form den 
Verknupfungstyp, der zu der jeweiligen virtuellen Ein- 
heit gehort. 
15 % 

blsConf igurable : Dieses Flag zeigt an, ob die zugehorige phy- 
sikalische Teileinheit konfiguriert werden muJS, um diese 
virtuelle Einheit zu erhalten. 

20 uiConfBits: Falls blsConf igurable ===== TRUE ist, werden hier 
die zugehSrigen Konf igurationsbits gespeichert, um die 
physikalische Teileinheit fur exakt. diese Funktion zu . 
konf igurieren. 

25 uiConfBitsIndex: Falls blsConf igurable == TRUE 1st, wird der 
Index zur Speicherung der Konf igurationsbits im Bitstrom 
an dieser Stelle gespeichert. 

bTwoSourceRegs : Dieses Flag wird auf TRUE gesetzt, falls fiir 
30 den betreffenden Befehl zwei Sourceregister angegeben 

werden miAssen, ansonsten auf FALSE. 

uiSrcMultiplexNumber [2] : Bei zwei Sourceregistern werden die 
physikalischen Nummern der zugehorigen Multiplexer in 
35 dieser Variablen gespeichert, gegebenenf alls ist nur die 

, Variable mit dem Index 0 gultig. 
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uiSrcMultiplexIndex [2] : Hier werden die Indizes der Multi- 
plexer fur die Sourceregister gespeichert . 

bDes tinatiohReg : Dieses Flag wird'auf TRUE gesetzt, falls fur 
5 den betref f eriden Befehl ein Destinatidnregister (nicht 

flag! ) angegeben werden muB, ansonsten, auf FALSE. 

uiDestMultiplexNumber : Hier wird die physikalische Nummer des 
zugehorigen Multiplexers fur das Zielregister gespei- 
10 chert. 

uiDestMultiplexIndex : Hier wird der Index des Multiplexer-:, fur 
das Destinationregister gespeichert . 

15 blsUsed: In diesem Flag wird gespeichert, ob diese virtuelle 
(und damit zugleich die physikalische) Teileinheit be- 
nutzt wurde. Ein Setzen dieses Flags auf TRUE bedeutet, 
daB diese Teileinheit nicht mehr genutzt werden kann 
(aulier bei den bedingten Move-Bef ehlen (movep) ) . 

20 

bSecondPIsUsed: Fiir den Sonderfall der movep-Bef ehle wird in 
diesem Flag die zweite Nutzung eines p- Flags einschlieii- 
lich des Vergleichs gespeichert. Sind blsUsed und 
bSecondPIsUsed auf TRUE gesetzt, ist der dynamische 
25 Wegmultipiexer (AU) , auf den ein movep-Bef ehl abgebildet 

wird, zur weiteren Nutzung gesperrt. 

blsConstantRegister: Dieses Flag zeigt an, daB die physikali- 
sche Teileinheit einem Konstantenregister entspricht 
30 (TRUE) Oder nicht (FALSE) . 

uiConstantlndex: Im Fall eines Konstantenregisters muB der 

Wert der Konstanten, der gespeichert und genutzt werden 
soil, im Bitstrom eingetragen werden. In diesem Fall ist 
35 der Index im Bitstrom in dieser Variablen gespeichert. 
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uiConstantValue: Der Wert, der im konstantenregister gespei- 
chert wird, wird fur weitere Vergleiche zusatzlich in 
dieser Variablen der Instanz gespeichert . 

Die in einer Instanz dieser klasse auf tretenden Variablen . . 
mtissen alle zum Zeitpunkt des Starts der Konf iguration belegt 
werden. Hierzu werden hier nicht explizit auf gefiihrte Metho- 
den benutzt, die im Konstruktor einer nachfolgend erlauterten 
Configurable-Block- bzw. CB-Klasse genutzt werden, urn alle 
filr die Umsetzung notwendigen Inf ormatipnen in die Instanz zu 
schreiben und zugleich die Flags blsUsed und bSecondPIsUsed 
auf FALSE zu setzen. Wahrend der Lebenszeit dieser Instanz 
andern sich dann nur noch diese beiden Flags, die liber vor- 
definierte Methoden mit dem Wert TRUE bzw. FALSE belegbar 
sind, sowie - im Fall eines Konstantenregisters - die 
Variable uiConstantValue, in der der aktuelle Wert des Regi- 
sters fur weitere Vergleiche zwischengespeichert wird. 

Von den Methoden der vorstehend definierten Klasse fur die 
virtuellen Einheiten bedeuten: 

unsigned int uiGetPartNumber ( void ) : Diese Methode gestattet 
den lesenden Zugriff auf die Nummer der zur virtuellen 
Teileinheit gehorenden physikalischen Teileinheit; die 
Nummer wird als RUckgabewert zuriickgelief ert . 

unsigned int uiGetMnemonicType ( void ) : Diese Methode gestat- 
tet den lesenden Zugriff auf Mnemonic, der in der vir- 
tuellen Einheit implement iert werden kann* 

BOOL blsUnitConf igurable ( void ) : Diese Methode lief ert TRUE, 
falls die physikalische Teileinheit konfiguriert werden 
. mufi. Unter dies en. Urns tanden sind die Eintrage in uiConf- 
Bits und uiConfBitslndex giiltig und konnen mit den fol- 
genden Methoden uiGetConfBits () und uiGetConfBitsIndex ( ) 
erhalten werden. Ferner mtissen alle anderen virtuellen 
Teileinheiten, die zur gleichen physikalischen Einheit 
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gehoren, ebenfalls gesperrt werden. Fur den Rtickgabewert 
FALSE hingegen sind virtuelle und physikalische Einheit 
identisch. 

5 unsigned int uiGet Con f Bits ( void ) : Durch diese Methode wer- 
den die Konf igurationsbits gelesen urxd als Riickgabewert 
zurtickgelief ert . Diese Werte sind nur giiltig, wenn 
blsConf igurable den Wert TRUE besitzt. 

10 unsigned int uiGetConfBitsIndex ( void ): /Durch diese Methode. 
wird der Index im Bitstrom ftir die Konf igurationsbits 
gelesen und als Rtickgabewert zurlickgelief ert . Dieser 
Wert ist nur giiltig, wenn blsGonf igurable den Wert TRUE 
besitzt. 

15 ; 

BOOL bHasTwoSourceRegs ( void ): Ein Aufruf dieser Methode 
lief ert den Wert TRUE, falls diese Operation zwei 
Sourceregister besitzt und diese in die entsprechenden 
Multiplexer einzutragen sind, ansonsten den Wert FALSE. 

20 

unsigned int uiGetSrcMultiplexNumber ( unsigned int ) : Diese 
Methode liefert die Nummer der physikalischen Teil- 
einheit, die den Multiplexer fiir die Sourceregister dar- 
stellt. Aufruf parameter ist der Index in dem Array von 2 
25 Eintragen, wobei der Index 1 nur guitige Werte liefert, 

falls das Flag bHasTwoSourceRegs den Wert TRUE besitzt. 

unsigned int uiGetSrcMultiplexIndex ( unsigned int ) : Diese 
Methode liefert den Index zum Eintrag in den Bitstrom, 
30 um die Konf igurie rung des Multiplexers fiir die Source- 

register vornehmen zu konnen. Aufruf parameter ist der 
Index in dem Array von 2 Eintragen, wobei der Index 1 
nur giiltige Werte liefert, falls das Flag bHasTwoSource- 
Regs den Wert TRUE besitzt. 

35 

BOOL bHasDestinationReg ( void ) : Ein Aufruf dieser Methode 

liefert den Wert TRUE, falls diese Operation ein Desti- 
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nationregister besitzt und dies in den entsprechenden 
Multiplexer einzutragen ist, ansonsten den Wert FALSE. 

unsigned int uiGetDestMultiplexNumber ( void ) : Diese Methode 
lief ert die Nummer der physikalischen Teileinheit, die 
den Multiplexer fur das Destinationregister darstellt. 
Der Ruckgabewert ist nur gtiltig, falls das Flag bHas- 
DestinationReg den Wert TRUE besitzt. 

unsigned int uiGetDestMultiplexlndex ( void ) : Diese Methode 
lief ert den Index zum Eintrag in den Bitstrom, urn die 
Konfigurierung des Multiplexers fur das Destination- 
register vornehmen zu kdnnen . Der Ruckgabewert 1st nur 
gtiltig, falls das Flag bHasDestinationReg den Wert TRUE 
besitzt. 

void vFreePart ( void ): Diese Methode loscht alle Belegungs- 
flags, indem diese mit dem Wert FALSE belegt werden. 
Hierin erfolgt also ein schreibender Zugriff auf die 
Flags . 

BOOL bMarkUsedPart ( void ) : Das Belegtflag blsUsed wird uber 
diese Methode auf TRUE gesetzt. Ruckgabewert ist TRUE, 
falls die Operation erfolgreich war/ FALSE, falls dieses 
Element bereits belegt war. 

BOOL bMarkSecondUsedFlag ( void ) : Das zweite Belegtflag 

bSecondPIsUsed wird entsprechend auf TRUE gesetzt. Ruck- 
gabewert ist auch hier TRUE, falls die Operation erfolg- 
reich war, FALSE, falls dieses Element bereits belegt 
war 

BOOL bGetIsUsed( void ): Diese Methode lief ert als Ruckgabe- 
wert den Wert der Variablen blsUsed. 

BOOL bGetlsUsedSecondFlag ( void ) : Diese Methode lief ert als 
Ruckgabewert den Wert der Variablen bSecondPIsUsed. 
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BOOL blsConstantRegister ( void ) : Diese Methode gibt TRUE zu- 
rttck, fails die virtuelle Teileinheit einem Kons tan ten- 
register entspricht, ansonsteri FALSE. 

BOOL bSetConstantValue ( void ) : Mit Hilfe dieser Methode kann 
der aktuelle Konstantenwert in der Variablen uiConstarit- 
Value gespeichert werden, falls diese virtuelle Einheit 
einem Konstantenregister entspricht und dieses bisher 
10 noch nicht belegt wurde . Rtickgabewert ist TRUE fur Er- 

folg, FALSE sonst . 

unsigned int uiGetConstantValue ( void ) : Mit Hilfe dieser 

Methode wird der gespeicherte Konstantenwert zuriickgege- 
15 ben. 



20 



unsigned int uiGetConstantlndex ( void ): Der Index in den 
Bitstrom, der ftir die Speicherung des Konstantenwerts 
dort notwendig ist, wird uber diese Methode erhal ten. 



Fur die Modellierung eines Hardware-Blocks (CBs) wird eine 
zweite Klasse definiert, die u.a. Instanzen der Klasse 
clVirtualUnit sowie weitere Variablen und Methoden enthalt. 
Zur Vereinf achung wird eine Speicherung der Elemente in einem 
25 statischen Array angenommen; eirie verkettete Liste ist natttr- 
lich ebenfalls denkbar. Essei an dieser Stelle angemerkt, 
daB fur die hier angegebenen Klassen nur ein Teil der Metho- 
den dargestellt wird. 

30 class clCB 

{ • '•■ : ' . ... : '- . 

private: BITFIELD *clbitfield; 

class clVirtualUnit clArrayVirtualUnits 

[NUM_OF_PARTS] ; 

35 



public: 



clCB ( ) ; 

void vSetupBitfield( BITFIELD *) ; 
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void vFreeAll ( void ); 

BOOL bDoAllPhase_l_Parts •• ■■< 

( unsigned int, BITFIELD * ) 
BOOL bDoCommonPhase_2_Parts ( unsigned int, 
"5: BITFIELD * , 

unsigned int/ 
unsigned int, 
unsigned int ) ; 
void vDataForwarding ( unsigned int, unsigned int' ); 
10 void vCopyBitf ield ( BITFIELD ■*, BITFIELD * ); 

unsigned int uiGetMuxCode { unsigned int, 

unsigned int ); 
unsigned int uiGetRegPartNumFromCode 

( unsigned int ) ; 
15 . unsigned int uiGetPartNumFromFlag 

( unsigned int ) ; 
unsigned int uiGetlndexFromNum ( unsigned int-);;. 
unsigned int uiGetPartNumFromBitf ield 

( unsigned int ) ; 

20 void vSetBitfield( unsigned int, unsigned int, 

unsigned int ) ; 

}; . . 



25 Die Variablen und Methoden der Klasse clCB bedeuten im ein- 
zelnen: 

BITFIELD *clBitf ield: Diese Variable entspricht dem zu gene- 
rierenden Bitstrom ftir eine Lauf zeitkonf iguration des 
30 CB. 

class clVirtualUnit clArrayVirtualUnits [NUM_OF_PARTS] : Dieses 
Array von Instanzen der Klasse clVirtualUnit enthalt 
alle Informationen ftir alle virtuellen Einheiten und 
35 soiriit . auch fur alle physikalischen Teileinheiten. 
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clCBO : Dieser Kpnstruktor wurde aufgefuhrt, urn zu verdeutli- 
chen, woiriri* die Aufgaben dieser Klasse bestehen. In 
einer Startphase miissen sowohl das Bitfeld als auch alle 
instanzen der klasse clVirtiialUnit , die im Array 
clArrayVirtualUnits [ ] zusamengef afit werden, ihi- 
tialisiert .werden. Zur Initialisierung der Klassen- 
instanzen zahlen insbesondere das Beschreiben aller 
Konf igurationsdaten sowie das Rticksetzen aller Flags, urn 
in der Betriebsphase auf die notwendigen Daten lesend 
zugreif en zu konnen. 

void vSetupBitf ield ( BITFIELD * ) : In dieser Methode wird das 
Bitfeld mit alien Vorbeleguhgen versorgt . 

void vFreeAll ( void ): Diese Methode wird zum Loschen aller 
Belegtflags in dem Array clArrayVirtualUnits [ ] aufgeiru- 
f en. 

BOOL bDoAHPhase_l_Parts (unsigned int, BITFIELD * ): In die- 
ser Methode sind alle Teile zur Phase 1 zusammengef afit . 
Sie wird aufgerufen, nachdem eine freie Teileinheit zur 
Aufnahme des Mnemonics gefunden wurde und enthalt die 
Markierung aller zugehorigen virtuellen Einheiten als 
beset zt, Bestimmung der Konf igurationsbits und des Index 
in den Bitstrom und Eintragung in einen tempo rar en 
Bitstrom. Parameter sind der Index in dem Array der vir- 
tuellen Einheiten und der Zeiger auf den temporaren 
Bitstrom. Der RUckgabewert TRUE zeigt eine erfolgreiche 
Phase 1 an, FALSE den MiJJerfolg (etwa durch nicht aus- 
reichende Netzressourcen) . 

BOOL bDoCommonPhase_2_Parts ( unsigned int, BITFIELD *, 

unsigned int, unsigned int, unsigned int) : Diese Methode 
fafit die f Ur alle Bef ehlsgruppen gemeinsamen Methoden 
zusammen. Hierzu zahlen die Eintrage ftir die Source- und 
Destinationregister einschliefilich der Behandlung der 
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Konstanten als Eihgabewerte . Ruckgabewert ist TRUE far 
Erfolg und FALSE ftir Mifierfalg. 

void vDataForwarding ( unsigned int, unsigned int) : Die Be- 
rechnung des Data Forwarding mit alien zugehorigen 
Methoden ist in dieser Methode iritegriert. Die Vor- 
gehensweise betrifft die Sourceregister, deren physika- 
lische Nummer in den Parametern iibergeben werden. Unter 
Nutzung weiterer Methoden wird ermittelt, ob ein Source- 
register bereits ein frUheres Destinationregister war. 
1st dies der Fall, wird die letzte berechnende AU aus 
dem Bitstrom ermittelt und ans telle des Registers ein- 
getragen. 

void vCopyBitf ield ( BITFIELD *, BITFIELD *) : Diese Methode 

verkniipft die Eintragung in dem zweiten Bitstrom mittels 
ODER mit denen des ersten und speichert das Ergebnis im 
ersten Bitstrom, Hierdurch wird das temporare Zwischen- 
ergebnis im zur spateren Konf iguration berechneten 
. Bitstrom gespeichert. 

unsigned int uiGetMuxCode ( unsigned int, unsigned int) : Diese 
Methode berechnet die Konf igurationsbits, die fUr einen 
Multiplexer in den Bitstrom zu laden sind, urn als Quelle 
eine physikalische Teileinheit auszuwahlen. Parameter 
dieser Methode sind die physikalische Nummer des Multi- 
plexers sowie der Quelleinheit . Diese Methode ist un- 
bedingt notwendig zur Konf iguration, da in der Beschrei- 
bung der virtuellen Einheiten zwar der Index des Ein- 
trags, nicht jedoch der Eintrag selbst gespeichert wird. 
Diese Methode kann flir ein vollstandiges Netzwerk als 
tabeliengesttitzte Umrechnung gegebenenf alls ohne Beriick- 
sichtigung der Multiplexernummer implementiert sein, da 
in diesem Fall alle Multiplexer auf einheitliche Weise 
konf igurierbar sind. Filr partielle Netzwerke muB hier 
grofierer Aufwand betrieben werden, insbesondere kann 
eine Vernetzung unmoglich sein. Rtickgabewert sind die 
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Konf igurationsbits im Erfolgsfall bzw. eine sonst un- 
genutzte Codierung fur den Fall des Mifierfolgs. 

unsigned int uiGetRegPartNumFromCode (unsigned int) : Diese 
5 Methode berechnet die Nummer der Teileinheit aus dem 

Code in der Instruktion. Dies kann naturgemaB nur fUr 
Register erfolgen, wobei im Fall einer Konstanten die 
beschriebene Vorgehensweise in dieser Methode integriert 
ist, die zur Speicherung der Konstanten und zur Ruckgabe 
10 der physikalischen Nummer des Konstantenregisters f iihrt • 

Ruckgabewerte sind die Nummer der Teileinheit im Er- 
folgsfall, ansohsten eine nicht benutzte Kennung ftir den 
MiBerf olg- 

15 unsigned int uiGetPartNumFromFlag (unsigned int): Ftir die Urn- 
rechnung einer Flagnummer in die Nummer der physikali- 
schen Teileinheit ist diese Methode zustandig. Aufruf- 
parameter ist das p-Feld in dem Instruktionsf ormat, 
RUckgabewert die Teileinheitsnummer oder eine besondere 

20 Kennung im Fall des MiBerfolgs. 

unsigned int uiGetlndexFromNum (unsigned int): Mit Hilfe die- 
ser Methode wird der Index in den Bitstrom fUr eine 
Teileinheit mit bekannter physikalischer Nummer (als 
25 Parameter) berechnet und zurUckgegeben* Diese Berechnung 

kann in Tabellenform erfolgen. 

unsigned int uiGetPartNumFremBil field (unsigned int): Diese 
Methode liest den Eintrag in dem Bitfeld an dem als 

30 Parameter tibergebenen Index und rechnet die erhaltene 

Konf igurationsmaske in die physikalische Nummer der 
Teileinheit zurtick, die als Ergebnis zurtickgegeben wird. 
uiGetPartNumFromBitf ield wird im Data Forwarding ein- 
gesetzt, wo der Datenweg von eihem frtiheren Zielregister 

35 auf die das Ergebnis bestimmende Teileinheit zurtick- 

verfolgt wird v damit die Daten vorzeitig verwendbar 
sind. 
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void vSetBitf ield { unsigned int, unsigned int, unsigned int): 
Diese Methode wird mit drei Parametern aufgeruf en : Der 
Index der Eintrags, die Lange des Eintrags und die 
Maske. Der Aufruf bewirkt den Eintrag in dem Bit f eld an 
der entsprechenden Stelle. 

Mit den vorstehend genannten und erlauterten Variablen und 
Methoden ergibt sich folgender Pseudocode fUr das Verfahren 
zur der auf Befehlen oder Bef ehlsf olgen basierenden Konfigu- 
rierung eines Hardware-Blocks der in der Figur 12 dargestell- 
" ten Art (ftir die struktur-prozedurale Programmierung) : 

unsigned int k; 

BITFIELD *clTempBitfield; 

// 1. Phase: Bestimmung einer physikalischen Teileinheit zur 
// Aufnahme der Verknupfung. 
// mnenomic in uiMem stehend 

vSetupBitf ield ( clTempBitf ield ) / 

for ( k = 0; k < NUM_OF_PARTS; k++ ) 

if( clArrayVirtualUnits [k] : : uiGetMnenomic () == uiMem 

&& clArrayVitualUnit [k] : :bGetIsUsed ( ) == FALSE ) 
break; 

} 

if( k === NUM_OF_PARTS ) // Keine freie Verkntipfung gefundeh 
return ( FALSE ); 

// Jetzt wird die freie Teileinheit als besetzt markiert, 
// gegebenenf alls eine Konf igurierung bestimmt und in diesem 
// Fall auch alle anderen virtuellen Einheiten als besetzt 
//markiert. Alle Maskenbits werden in einem temporaren 
// Bitstrom gespeichert. 
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if ( bDoAHPhase_l_Parts { k, clTempBitf ield j === FALSE ) 
return ( FALSE ) ; 

7/ Niinmehr begirint die zweite Phase: Fur all e Instruktionen 
// werdeiv die be i den, gegebenenf alls ein Sourceregister 
// bestimmt und in den Bitstrom eingetragen. Entsprechendes 
// erfolgt mit dem Destinationregister, falls vorhanden. Die 
// entsprechenden Codierungen aus der Instruktion stehen in 
// den Variablen uiSourceRegl , uiSourceReg2 und uiDestReg, 
// wdbei gegebenenf alls Konstanten als Quellen hier erkennbar 
// sind. 

if( bDoPhase_2_CommonParts ( k, clTempBitf ield uiSourceRegl , 
uiSourceReg2, uiDestReg == FALSE ) 
return ( FALSE ); 

switch ( uiMnemonicType ) 
{ 

case BEDINGTER_BEFEHL // p-Flag bestimmen, Eintrag fur CU 
case MOVEP__BEFEHL: // spez. erster Eintrag, 

// zweiter Eintrag moglich 

} 

vDoDataForwarding ( uiSourceRegl, uiSourceReg2 ) ; 

// Die letzte Aktion: Der temporar gespeicherte Bitstromcode 
// wird in den eigentlichen Bitstrom kopiert 

vCopyBitfield( clBitfield, clTempBitf ield ) ; 
return ( TRUE ) ; 

Die yorstehende zentrale Routine wird ftir jede Instruktion, 
die tibersetzbar -ist, aufgerufen. Riickgabewert ist TRUE, falls 
die Umsetzung gelungen ist, ansons ten FALSE. Im letzteren 
Fall mufl die Instruktion im aufrufenden Programm behalten 
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werden, da sie nicht eingefugt wurde,. und der Bitstrom kann 
zur Ausfiihrung ge laden werden. Das Ende einer Umsetzung wird 
also durch das Erschopfen der Ressourcen angezeigt oder durch 
eine nicht-tibersetzbare Instruktion wie beispielsweise einen 
5 Branchbef ehl erhalteh. 

Wie vorstehend bereits erwahnt wurde, lafit sich die struktur- 
prozedurale Programmierung nicht nur sof twaremaJJig, sondern 
auch hardwaremaliig realisieren. Eine mogliche Ausf iihrungsform 
10 einer hardwaremafiigen Realisierung wird nachfolgend unter Be- 
zugnahme a~uf~~dre— Frguren 2 bis 10 erlautert. Dabei wurde ver- 
sucht, die einzelnen Phasen so weit wie moglich parallel 
durchlauf en zu lassen. 

15 Die bei der sof twaremaliigen Realisierung vorkoramenden tabel^ 
lengestiitzten Umrechnungen werden bei der hardwaremaJJigen 
Realisierung als sogenannte Look-Up-Tables (LUTs) realisiert. 
LUTs sind dazu ausgelegt, im Ansprechen auf die Eingabe von 
Daten von diesen abhangende Daten auszugeben. Solche LUTs 

20 konnen beispielsweise durch ein EPROM Oder eine andere 

Speichereinrichtung gebildet werden. Die eingegebenen Daten 
werden dann als Adresse verwendet, und die ausgegebenen Daten 
sind die unter dieser : Adresse gespeicherten Daten. 

25 Ftir die erste Phase wird eine LUT der in der Figur 2 ver- 

anschaulichten Art verwendet. Diese LUT weist zwei Eingange 
(Address, Counter^Address) und vier Ausgange (Code, Comple- 
mentary, Counter_Up, No_Entry) auf. Die zwei Eingange dienen 
der Adr ess ierung der LUT, wobei die liber den einen Eingang 

30 (Address) zugeftihrten Daten und/oder Signale vom zu tiber- 
setzenden Code abhangen, und wobei die liber den anderen 
Eingang (Counter_Address) zugeftihrten Daten und/oder Signale 
Zahlstande eines durch den Ausgang Couhter_Up hochzahlbaren 
Zahlers (Zahler-Arrays) sind. Die Ausgange dienen zur Ausgabe 

35 des ubersetzten Codes (Code) , von Signalen zum Hochzahlen des 
die Counter_Address generierenden Zahlers oder Zahler-Arrays 
( Count er_Up ) , eines Signals zur Signalisierung ftir den Fall, 
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dafi kein gliltiger und freier Eintrag mehr vorliegt 
(NoJEntry) , und eines fUr die Bearbeitung bedingter Move- 
Befehle (movep) benotigten Signals (Complementary), wobei 
sich der ubersetzte Code aus Konf igurations-Bits (Config- 
5 Bits) , einem Konf igurationsindex (Conf ig-Index) , und einer 
Teilenummer (Part-Number) zusammensetzt . Die Look-Up-Table- 
Eintrage haben damit fur den ersten Teil das in Figur 3A 
gezeigte Format. 

: 10 Der erwahnte Zahler (das Zahler-Array) wird als Markierungs- 
mittel (beset zt, schreibend) verwendet, wobei fur jeden 
.'■ Operat ions-Typen (Addition, Subtraction . . . ) ein separater 
Zahler existiert. Der Zahistand der Zahler gibt an, die 
wievielte Moglichkeit zur Ausftihrung des zugeordneten 

15 Operations-Typs in Anspruch genommen werden kann. Die Tiefe 
der Zahler innerhalb dieses Zahler-Arrays hangt von der An- 
zahl der Moglichkeiten zur Ausftihrung der betreffenden 
Operation ab. Sind beispielsweise drei Additionsmoglichkeiten 
vorhanden, betragt die Zahlertiefe zwei Bit; in der korre- 

20 spondierenden LUT, die ja von dem Mnemonic-Code und dem 

Zahlerstand adressiert wird, wird dann allerdings an der 4. 
Stelle (Zahlerstand 3) eine NO^ENTRY-Codierung stehen, urn das 
Fehlen dieser Operation anzuzeigen; ein derartiger LUT-Ein- 
trag ist in Figur 3B veranschaulicht. 

25 ■ ' ' ■ 

Die besagten Zahler sind im betrachteten Beispiel Binarzahler 
mit asynchronem Reset und Enable. Ein 2-Bit-Binarzahler die- 
ser Art ist im betrachteten Beispiel wie folgt codiert; die 
Darstellung erfolgt in dem bei DNF (Disjunktive Normal-Form) - 

30 Logiken gebrauchlichen DNF-Format. Zahler dieser Art werden 
im folgenden als Zahler eines ersten Typs bezeichnet. 

BIT bO, blrOUT; 
BIT reset, enable: IN; 
35 BIT clock: IN; 



bO = /b0 * enable + bO * /enable; 
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bO.clk = clock; 
bO.areset = reset,; 

bl = /bl * bO * enable + bl * /bO * enable + bl * /enable; 
5 bi.clk = clock; 

bl . areset = reiset; 

Parallel zii diesen Zahlern muB fur die bedingten Befehle ein 
Speicherarray implementiert sein, urn den Code des Bedingungs- 
flags speichern zu konnen. Dies ist, wie vorstehend bereits 
erlautert wurde/ zur Zusammensetzung von Movep-Bef ehlen not- 
wendig. Da es nur eine CU-Instanz pro. Flag geben kann (im 
Gegensa.tz zu den AUs gibt es zwar im allgemeinen mehrere 
Flags, die sich jedoch alle durch die Bezeichnung des Bits 
unterscheiden) , besteht der Binarzahler aus zwei Bits, von 
denen das erste die Erstbelegung, und das zweite die Komple- 
mentarbelegung anzeigt. Die Identif izierung der kdrrekten CU 
erfolgt anhand der p~Bits aus dem Befehl. 

20 Die 2-Bit-Binarzahler ftir bedingte Move-Befehle sind im 
betrachteten Beispiel wie folgt codiert; die Darstellung 
erfolgt wiederum in dem bei DNF (Dis junktive Normal-Form)- 
Logiken gebrauchlichen DNF-Fprmat • Zahler dieser Art werden 
im folgenden als Zahler eines zwei ten Typs bezeichnet. 

: . 25- 

BIT bO, bl:OUT; 

BIT reset, enable: IN; 

BIT clock: IN; 

30 bO = /bO ■* enable + bO; 
bO.clk = clock; 
bO.areset = reset; 

bl = /bl * bO * enable + bl; 
35 bi.clk = clock; 

bl. areset = reset; 
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Ftir die Falle, in denen Entscheidungen getroffen werden mus- 
sen, die in Datenpfade umgesetzt werden, wird eine spezielle 
Logik integriert v 

5 Ftlr die 1. Phase des Verfahrerls zur Hardware-Block-Struktu- 
rierung ergibt , sich nach alledem die iii Fig. 4 gezeigte 
Realisierung. 

Fiir alle Befehle mit Ausnahme der bedingten Movep-Instruktio- 
10 nen wird pro arithmetischer Einheit AU bzw . pro Vergleichs- 
Einheit CU eine Zahlerinstanz nach Art des vorstehend erlau- 
terten Zahlers des ersten Typs benotigt. Ein solcher Zahler 
genugt, da nur ein einfaches Belegt-Signal benotigt wird. Die 
Movep-Anweisungen hingegen benotigen einen Zahler des zweiten 
15 Typs, der in zwei Bits die teilweise (bO) und die vollstan- 
dige (bl) Belegung signalisiert . Bedingte Movep-Instruktio- 
nen, die zum zweiten Mai auf das gleiche Flag ref erenzieren, 
miissen dieses in (im Vergleich zur ersten Referenz) inver- 
tierter Form vornehmen und werden dann in der entsprechenden 
20 AU als zweite Quelle eingetragen, wahrend das erste Quell- 
register unverandert bleibt. Dieses Verfahren ist in einer 
LUT integrierbar; Referenzen auf die nicht invertierten 
Bedingungen werden durch eine No_jEntry-Signalisierung ab- 
gebrochen. 

25 

Die zweite Phase umfallt die Bestimmung der Register, die ftir 
die betreffende Operation als Daten- und/oder Signalquelle (n) 
und Daten- und/oder Signalziel zu verwenden sind. Dies er- 
folgt ftir alle drei moglichen Register in paralleler und 
30 weitgehend identischer Form. Die Codierung des jeweiligen 

Registers innerhalb der Instruktibn wird - falls das betref- 
fende Feld einen gtlltigen Eintrag enthait - durch eine Look- 
Up-Table in eine Maske ftir den Bitstrom zusammen mit dem 
Index in den Bitstrom umgesetzt. 

35 

Das Blockschaltbild einer Schaltung zur Bestimmung und Codie- 
rung der als Daten- und/oder Signalquelle (n) und Daten- 
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und/oder Signalziel zu verwendenden Register ist in Figur 5 
veranschaulicht; die Identif izierung, welche der Register 
tatsachlich umgesetzt werden (miissen) , erfblgt im betrachte- 
ten Beispiel durch die Steuerleitungen Source_Reg 1, 
5 Source_Reg_2, und Dest_Reg (siehe Figur en 4 und 5). 

Source- und Destinationregister werden unterschiedlich behan- 
delt. Im Fall eines Destinationregisters wird der Eintrag 
markiert, urn eine Zweitbelegung identif izieren zu konnen 

10 (Signal No^Entry) und urn ein Data Forwarding zu triggern. 
Diese Signale entf alien ftir Sourceregister . Hier wird eine 
"straight-forward"-Generierung des Bitstromeintrags durch- 
geftihrt, wobei allerdings die Generierung des Codes im Fall 
einer Konstanten entfallt und auf die nachfolgend beschrie- 

15 bene Stufe verlagert wird. 

In der Figur 5 ist markiert, was ausschliefllich far Source- 
register und ausschliefllich ftir Destinationregister relevant 
ist: mit (*) gekennzeichnete Teile sind nur ftir Destination- 
20 register bestimmt, und mit (**) gekennzeichnete Teile sind 
nur fur Sourceregister bestimmt. 

Fur eine Konstante, die innerhalb der Codierung anstelle 
eines Sourceregisters auf tret en kann, wird ein paralleler Weg 

25 durchgeftihrt, der die Konstante mit den Inhalten aller Kon- 
stantenregister parallel zueinander vergleicht, und - bei 
Ungleichheit - das nachstfreie Register (Zeigerverwaltung 
durch einen Zahler) mit der Konstanten belegt und dieses 
Register als Codierung zurticklief ert oder - bei Gleichheit - 

30 die Codierung des die Konstante enthaltenden Konstantenregi- 
sters als Codierung zurticklief ert . 

Die Look-Up-Table wird zu diesem Zweck so gestaltet, dafi sie 
bei einem positiven Vergleich unmittelbar die Codierungs- 
35 nummer des betreffenden Registers zum Bitfeld lief ert, wah- 
rend im Fall einer NichtUbereinstimmung zusatzlich die Kon- 
stante gespeichert und der Regis terzahler erhoht wird. Das 
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No Entry-Signal wird fUr den Fall einer Belegung aller Kon- 
stanten aktiv und beendet den Algorithmus ftir einen Instruk- 
tionsblock, da die Res sour cen erschopf t sind. Es sollte zudem 
beachtet werden, daB die Konstantenregsiter ein Teil des 
(Main-) Bits troms sind, da sie ails vorhergehenden Zyklen be- 
reits belegt skin konnen und zum Laden des Iiis truktionsblocks 
benotigt werden. 

Das Blockschaltbild einer Schaltung zur Zuordnung der Kon- 
stantenregister ist in Figur 6 veranschaulicht. 

Fur Sourceregister wird das bereits mehrfach erwahnte Data 
Forwarding durchgefuhrt. Anhand der Eintragung in das 
Belegtflag des Registers, die anzeigt, daB dieses Register in 
diesem Zyklus bereits Zielregister war, wird entschieden, ob 
tatsachlich das Sourceregister oder die Eintragung, die als 
Quelle fur das Zielregister ermittelbar ist, als neue Quelle 
in den Bitstrom eingetragen wird. 

Das Blockschaltbild einer hierzu geeigneten Schaltung ist in 
Figur 7 dargestellt. 

Die im Figur 7 per LUT durchgefuhrte Umcodierung der neuen 
Quelle kannentf alien, falls alle Quellen innerhalb des Netz- 
werks identisch codiert werden* Dieser Fall, der fUr ein 
vollstandiges Netzwerk angenommen werden kann, fiihrt dazu, 
daB die im temporaren Bitstrom stehende Eintragung der Quelle 
ftir das (frtihere) Zielregister als neue Quell-Codierung ftir 
die jetzige Operation anstelle des in der Instruktion codier- 
ten Quellregis'ters eingetragen wird. Die Auswahl erfolgt in 
jedem Fall durch einen tiber das Signal Is_Data-Forwarding 
(siehe Figur 5) angesteuerten Multiplexer. 

Ftihren alie x Operationen zum Erfolg (dies ist anhand des Auf- 
tretens keiner No_Entry-Signalisierung erkennbar) , wird der 
temporare Bitstrom beim Schreibtakt mit dem vorhandenen 
Hauptbitstrom ODER-verkntipf t und in diesen zurtickgeschrieben. 
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Die Figuren 8 und 9 zeigen Blockschaltbilder zum Einschreiben 
von Konf igurationsdaten in den temporaren Bitstrom und in den 
Hauptbitstrom (main bitstream) . 
5 ■ ' • \ ' • " '' : ' r"-"" y 

Wie aus der Figur 8 ersichtlich ist, erfolgt das Einschreiben 
von Konf igurationsdaten in den temporaren Bitstrom ttber soge- 
nannte Cross-Bar-Switches. Cross-Bar-Switches sind allgemein 
bekannt und bediirfen keiner naheren Erlauterung. Sie leiten 

10 die Konf igurationsbits (Conf ig-Bits) an die durch den Config- 
Index definierten Stellen im temporaren Bitstrom, wobei unbe- 
legte Ausgange des Cross-Bar-Switch mit einem vorbestimmten 
Wert (beispielsweise "0") belegt sind. Fur die mnemonic- 
basierte Auswahl einer physikalischen Teileinheit, die Konfi- 

15 guration dqrselben und die Zuordnung der Source- und Destina- 
tionregister zu dieser ist jeweils ein eigener Cross-Bar- 
Switch gemaJi Figur 8 notwendig* 

Die Umsetzung des temporaren Bitstroms in den Hauptbitstrom 
20 (die Oberlagerung des Hauptbitstroms durch die Ausgange der 
Cross-Bar-Switches erfolgt durch ODER-Gatter OR am Eingang 
des Hauptbitstroms (siehe Figur 9). 

Die vorstehend beschriebenen Komponienten lassen sich wie in 
2'5 Figur 10 gezeigt zu einer Anordnung zusammenfugen, die in der 
Lage ist, aus m-bits, ksi-Bits, ks2-Bits, kd-Bits und p-Bits 
zusammengesetzte Befehle (siehe Figuren 1A bis ID) in Konfi- 
gurations-Daten zur Konf igurierung eines Hardware-Blocks 
umzusetzen und diese Daten in einen zur Konf igurierung des 
30 Hardware-Blocks verwendbaren Bitstrom einzuschreiben. 

AbschlieiSend wird die angestrebte Umsetzung (die struktur- 
prozedurale Programmierung) auch noch in mathematischer Nota- 
tion angegeben. 
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Hierzu mufl zunachst eine Reihe von die Darstellungen und die 
Abbildungen betreffenden Vereinbarungen getroffen werden. Es 
seien 
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r 

I 

SR 

CR 

SR + 
DR 

PR 

DR 4 
RN 
RN* 

List (pp) 
Nbit 



B 



30 OCC 



PP 

PLNUM 



35 PL 



die Menge aller Instruktionen 

die Menge aller Datenf luG-relevanten (fiir die 

Blockausfuhrung geeigneten) Instruktionen 

die Menge aller Sourceregister einschlieJilich NO- 

SOURCE-Darstellung/ ausschlieBlich der Konstanten- 

register ■ 

die Menge aller Konstantenregister einschlieJilich 
der Darstellungen fiir NO_CONST und IS_CONST 
SR o CR " 

die Menge aller Destinationregister einschlie/Jlich 
NO_DEST-Darstellung ausschlieBlich der Predicate- 
Bits 

die Menge aller Predicate-Bits einschliefilich 

NO_PRED 

DR PR 

die Menge aller Register, SR u CR u DR 

die Menge aller Register einschliefilich Predicate 

Bits, RN <u PR 

die Menge aller moglichen Werte fur den Bitstrom B 
als 4-Tupel (px e PP, offset < k, nbit < k, bitwert 
< 2 k - 1), gegebenenfalls abhangig von pp e pp 
die Menge der moglichen Bitwerte (bei n Bit Daten- 
breite: 0 . . 2 n - 1) 

die Menge von k binarwertigen Eintragen als der 
Bitstrom zur Konf iguration der Struktur 
die Menge aller Belegungsmarkierungen { FREE, WRITE, 
READ, READ_WR I TE } 

die Menge aller physikalischen Teileinheiten 

die Menge aller eindeutigen Nummern fiir die logi- 

schen Einheiten 

die Menge aller logischen Teileinheiten in einem 
CB, bestehend aus dem 11 -Tupel (pi e I <u RN*, 
plnum e PLNUM, pp e PP, occ e OCC, source e PLNUM, 
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val g Nbit, pbit g PR, List (pp) , konf Of f set < k, 
konfAnzahl < k, konf Wert < 2 k - 1) 

Bei der f olgenden Beschreibung werden einige Grundannahmen 
und Funk tidnen genutzt, die zunachst erlautert werden soli en. 
Die Kennung innerhalb der Komponente occ (fur occurence) 
wurde vierwertig gewahlt, um die Zustande 'nicht belegt 1 
(FREE), 'lesend belegt' (READ), ' schreibend belegt 1 (WRITE) 
und 'lesend und schreibend belegt 1 (READ__WRITE) kennzeichnen 
zu konnen. Die Kennung 'lesend belegt' wird dabei gegebenen- 
falls nicht weiter ausgewertet, aber dennoch innerhalb der 
Beschreibung weitergef tihrt . 

Weiterhin wird fur die Register aus RN angenommen, dafi fur 
diese Teileinheiten die logische und physikalische Darstel- 
lung iibereinstimmt . Dies bedeutet, dafi im Gegensatz zu man- 
cher funktionalen Teileinheit (etwa eine konf igurierbare 
Addition/Subtraktionseinheit die als zwei logische Einheiten 
dargestellt wird, aber natiirlich nur einmal belegbar ist) ftir 
Register keine Konf igurierung durchzufuhren ist, und dafi 
zwischen der Regis ternummer rh g RN und der logischen Teil- 
einheitsnununer plnum g PLNUM eine injektive Abbildung 
(gleichwohl nicht bijektiv) existiert, die im f olgenden mit 
rn2plnum() bezeichnet wird. Diese Annahme gilt nicht fur 
Predicate-Bits als Zielbits. 

Unter diesen Voraussetzungen lafit sich die : Umsetzung von 
Befehlen in Strukturinf prmationen zur Strukturierung von 
30 Hardware-Blocken wie folgt umschreiben: 

1. In der ersten Phase wird jede Instruction einschliefilich 
aller Operanden aus dem originalen Binarformat in eine 
. Beschreibung bi = (i g I, srl € SR, crl g CR, nl e 
35 Nbit, sr2 G SR, cr2 G CR, n2 G Nbit, dr g DR, pr_source 

G PR, pr_dest g PR) iibergefiihrt . In dieser Beschreibung 
wird ftir eine Konstante die Kennung IS_CONST fur crl 
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bzw. cr2 sowie der Konstantenwer.t in nl/n2 eingetragen, 
Wobei in dies em Fall das entsprechende Sourceregister 
die Kennung NOJSOURCE erhalt. Entsprechend wird ftir Pre 
dicate-Bef ehle (etwa pge . ftir dr NO_DEST eingesetzt, 
5 wahrend pr_dest dann die Nuinmer des Predicate-Bits 

■ tragt. :■* . 

Ftir Predicated Instructions (etwa movep) wird zur besse 
ren Unterscheidbarkeit nicht pr_destj sondern pr_source 
10 auf einen entsprechenden Wert gesetzt... 

Eine Instruktion mit j £ I bewirkt ein Beenden der Urn- 
set zung. 

15 2. In der zweiten Phase werden maximal funf Eintrage in bi 
in eine Konf iguration Ubersetzt. Funf deshalb, da sich 
einige Kombinationen gegenseitig ausschlieiien. Hierzu 
wird ftir die einzelnen Teile unterschieden: 

20 Ftir Instruktionen bi->i e l und bi-»pr_dest ~ NO_PRED 

(keine Predicate-Anweisung) wird das erste Element pi e 
PL gesucht, das dieses i abdeckt und occ == FREE auf- 
weist. 1st dies nicht auffindbar, so wird die Umsetzung 
beendet . 

25 

1st pi gefunden, so werden alle Elemente aus PL mit occ 
== READ_WRITE belegt, die auf das selbe physikalische 
Element pp g PP abgebildet sind. Die Konf iguration ftir 
pi wird in den Bitstrom B mit Hilfe der im Tupel vorhan- 
30 denen Inf ormationen eingetragen. 

1st bi-»pr_source == N<3_PRED, so wird hierftir keine Ein- 
tragung durchgef iihrt . Ansonsten wird nach einem p2 € 
PL mit p2-»pbit == bi-»pr_source gesucht, wobei p2->occ 
35 == WRITE sein muli. Ftir dieses p2 wird via List(p2— >pp) 

pi gesucht und die Eintragung in den Bitstrom vorgenom- 
men, aufierdem wird p2— >occ auf READ WRITE gesetzt. 
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Ftir Instruktionen bi-»i e I und bi-»pr_dest != NO_PRED 
( Pre die a t e -An we i sung ) wird das erste Element pi e PL 
gesucht, das dieses i abdeckt und occ — FREE aufweist. 
1st dies nicht auffindbar, so wird die Umsetzung be- 
endet . •■- 

1st pi gefunden, so werden alle Elemente aus PL mit occ 
= WRITE belegt, die auf das selbe physikalische Element 
pp g PP abgebildet sind. Die Konf iguration ftir pi wird 
in den Bitstrom B mit Hilfe der im Tupel vorhandenen 
Inf ormationen eingetragen. 

Ftir alle Instruktionen i e I gilt: Fur bi->srl und 
bi->sr2, ftir die != NO_SOURCE gilt, wird durch 
List(pl-»pp) die entsprechende Konf iguration in den 
Bitstrom B eingesetzt, falls fiir die zu srl/2 gehorigen 
pll/12 e PL, pll->occ == FREE, und pl2-»occ FREE 
gilt, zudem wird pl->plnum bei pll/12-^source eingetra- 
gen (fUr spateres Forwarding), 1st dies nicht der Fall, 
wird Phase 3 (Data Forwarding) durchgef iihrt . 

FUr die Sourceregister bi->srl und bi-»sr2 wird, falls 
diese != NO_SOURCE sind, in PL die entsprechenden Ein- 
trage fiir die zugehorigen p31 und p32 e PL (erhaltlich 
tiber die angegebene Funktion rn2plnum()) p31— »occ und 
p32-»occ auf READ gesetzt, falls diese vorher != WRITE 
und != READ_WRITE waren, ansonsten auf READ_WRITE. 

Ftir die Konstantenregister crl und cr2 wird, falls diese 
!= NOJIONST sind, zunachst fiir alle p3 e PL geprtift, ob 
p3->pp e CR, p3->occ == READ_WRITE, und p3— >val == 
bi— >nl/2 gilt. 1st dies der Fall, wird die Eintragung 
fiir p3 entsprechend dem Verfahren fiir ein Sourceregister 
durchgef iihrt. 
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Fiihrt diese Suche nicht zum Erfolg, mufi ein p3 e PL ge- 
sucht werden, fiir das p4— >pp e CR und p4-^occ == FREE 
gilt. 1st dies gefunden, wird bi-»nl/2 in p4-»val ein- 
getragen und p4-»occ = READ_WRITE gesetzt sowie die Ein- 
tragung wie bei einem Sourceregister f ortgef iihrt . 1st 
die Suche erf olglos, wird die Umisetzung beendet. 

Ftir das Destinationregister dr wird gepriift, ob fur den 
entspreehenderi Eintrag p5 mit p5— >pp — dr die Bedingung 
p5-*occ-== FREE oder READ gilt. 1st dies nicht der Fall, 
wird die Umsetzung beendet, ansonsten wird p5-*occ = 
WRITE oder READ_WRITE gesetzt und die Eintragung in 
List (p5-»pp) wird in den Bitstrom B iibertragen. Ftir ein 
eventuelles Data Forwarding wird p5-^>source - pi 
(logisches Element der wertgebenden Instruktion) einge- 
tragen. 

Ftir alle Sourceregister sr e SR, die in Phase 2 den 
Wert fur das zugehorige Element p6 e PL den Wert p6— >occ 
— WRITE oder READJtfRITE aufweisen, wird ein Data For- 
warding durchge ftihrt, indem in den Bitstrom B nicht die 
Werte aus List (p6) , sondern aus List (p6— >source) ein^ 
getragen wer den . 

25 Durch die vorstehend beschriebene Konf igurationsdaten- 

Erzeugung konnen Befehle von normalen Programmen, d.h. von 
Programmen, die zur Ausftihrung in nach dem von-Neumann- 
Prinzip arbeitenden programmgesteuerten Einheiten (her- 
kommlichen Mikroprozessoren, Mikrocontrollern etc.) ausgelegt 

30 sind, in konf igurierbaren Hardware-Blocken zur Ausftihrung 
gebracht werden. 

Die Art und Weise der Umsetzung ermoglicht es dabei, dafi 
sbwohl die Umsetzung der Befehle in die Konf igurationsdaten 
35 als auch die Hardware-Block-Konf igurierung unter Verwendung 
dieser Konf igurationsdaten besonders schnell, einfach und 
effizient erfolgen konnen. 
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Durch die beschriebene Umsetzung von Befehlen in Konfigura- 
tionsdaten wird eine Folge yon Konfigurationsciatensatzen 
erzeugt, wobei 

5 ' • . "" """" • ' :■ ""' 

- einerseits jeweils moglichst viele Bef ehle in einen Kon- 
figurationdatensatz umgesetzt werden, und 

- andererseits jeweils nur so viele Befehle in einen Kon- 
10 f igurationsdatensatz umgesetzt werden, wie durch die zum 

Zeitpunkt der Hardware-Block- (Urn-) Konf igurierung verftig- 
baren Ressourcen des Hardware-Blocks ausfOhrbar sind. 

Dadurch kann bei einer minimalen Anzahl von Umkonf igurierun- 
15 gen des Hardware-Blocks und ohne komplizierte und fehler- 
trachtige Oberpriif ungen vor der Verwendung der Konfigura- 
tionsdaten ein maximal effizienter Einsatz der Hardware- 
Blocke gewahrleistet werden • 

20 Dies gilt in besonderem Mafie (aber zweifellos nicht aus- 

schlielilich) , wenn ein Hardware-Block nach Art der Figur .12 
der vorliegenden Anmeldung verwendet wird und dieser durch 
die jeweiligen Konf igurationsdatensatze jeweils komplett 
umkonf iguriert wird. 

25 

Ein Hardware-Block dieser Art, der unter Verwendung eines wie 
beansprucht erzeugten Konf igurationsdatensatzes konfiguriert 
ist, fuhrt die in den betref fenden Konf igurationsdatensatz 
umgesetzten Befehle parallel aus. Wenn der Hardware-Block die 

30 in den betref fenden Konf igurationsdatensatz umgesetzten 

Befehle ausgeftihrt hat, was der Hardware-Block vorzugsweise 
(beispielsweise durch das erwahnte READY- Signal oder auf 
andere Art und Weise) signalisiert, wird der Hardware-Block 
unter Verwendung des nachsten Konf igurationsdatensatzes 

35 umkonf iguriert, wodurch die nachsten Befehle (die zu deren 
Ausftihrung . auszufiihrenden Operationen) im Hardware-Block 
ausgefiihrt werden. Dieser nachste Konf igurationsdatensatz, 
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unter Verwendung dessen die Umkonf igurierung erfolgt, resul- 
tiert aus einer wie vorstehend beschrieben pder ahnlich 
durchgeftthrten Umsetzung der nachsten Befehle. Wenn diese 
nachsten Befehle ausgefuhrt sind, erfolgt erneut eine Um- 
konf igurierung des Hardware-Blocks. Dabei wiederholen sich 
die erwahnten Vorgange. 

Auf diese Weise konnen zur Ausfiihrung in nach dem von- 
Neumann-Prinzip arbeitenden programmgesteuerten Einheiten 
ausgelegte Programme schnell (insbesondere wegen der zu- 
mindest teilweisen parallelen Bef ehlsausf tihrung erheblich 
schneller als in herkommlichen programmgesteuerten Einheiten) 
und einfach in konf igurierbaren Hardware-Blocken ausgefuhrt 
werden, 

Bei der vorstehend beschriebenen Umsetzung Bef ehlen in Kon- 
figuratiorisdaten wird eine hyperblockweise Umsetzung, d.h. 
eine Umsetzung, bei welcher genau ein Hyperblock in eine 
Konf igurationsdaten-Einheit umgesetzt wird, als das an- 
zustrebende Ziel angesehen. 

Noch besser ware es naturlich, wenn mehr als ein Hyperblock 
in einen Konf igurationsdatensatz umgesetzt werden konnte; 
dann konnte jeweils die maximale Anzahl yon Bef ehlen gleich- 
zeitig zur AusfUhrung gebracht werden. Dies ist unter be- 
stimmten UmstSnden sogar moglich. 

Insbesondere konnen bei Hardware-Blocken nach Art der Figur 
12 (bei Hardware-Blocken, die die vorstehend bereits erwahn- 
ten Predicate-Befehle ausfUhren konnen) die Hyperblocke 0, 1 
und 2 der Sequenz 

Hyperblock_0; 
if (condition) 

Hyperblock_l; 
else 

Hyperblock 2; 
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in einen einzigen Konf iguratiorisdatensatz umgesetzt werden . 
Dies wi.rd durch. die vorstehend bereits erwahnte if-Konversion 
moglich. Dabei kann die Bedingung (condition) in ein p-Flag 
5 umgesetzt werden/ und die Ausfiihrung der abhangig von dieser 
Bedingung aus zuf xihr enden Befehle vom Wert des p-Flag abhangig 
gemacht werden. Dabei kann beispielsweise vorgesehen werden, 
dafi die im if~Zweig (Hyperblock_l ) enthaltenen Befehle aus- 
geftihrt werden, wenn das p-Flag den Wert 1 hat, und dafi die 
10 im else Zweig (Hyperblock_2) enthaltenen Befehle ausgeflihrt 
werden, wenn das inverse p-Flag den Wert 1 hat. Aus den 3 
HYperblocken 0, 1 und 2 kann so ein diese umfassender Pseudo- 
Hyperblock gebildet werden, der in einen einzigen Konfigura- 
tionsdatensatz umsetzbar ist . 

15 

Ein solcher Pseudo-Hyperblock kann seinerseits wiederum einen 
oder mehrere Pseudo-Hyperblocke enthalten. Ein Beispiel hier- 
ftir ist die Sequenz 

20 Hyperblock_0; 
if (condition) 

Pseudo-Hyperblock__l ; 
else 

Pseudo-Hyperblock_2; 

25 

In diesem Fall kann ein Pseudo-Hyperblock gebildet werden, 
der den Hyperblock 0 und die Pseudo-Hyperblocke 1 und 2 
umf afit . 

30 Bei der Urns etzung von Befehlen in Konf igurationsdaten wird 
daher nach Moglichkeit in einem ersten Schritt versucht, 
Pseudo-Hyperblocke zu bilden. Hierzu ist es erf orderlich, die 
Programmstruktur danach zu untersuchen, ob sich Pseudo- 
Hyperblocke bilden lassen, und bei den zur Bildung von 

35 Pseudo-Hyperblocken in Frage kdmmenden Programmteilen eine 
if-Konversion durchzuftihren. 
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In bestimmten Fallen, insbesondere wenn durch einen kon- 
f igurierbaren Hardware-Block "nur" eine bestimmte Schaltung 
(beispielsweise eine serielle Schnitts telle) realisiert 
werden soil/ kann es sich als yorteilhaft erweisen, wenn der 
5 Hardware-Block unter Verwendung einer in einer Schaltungs- 
beschreiburigssprache wie beispielsweise VHDL erfolgten 
Sbhaltungsdef inition konf iguriert wird. Hierzu definiert man 
die Schaltung, die man durch den Hardware-Block realisiert 
haben mochte, zunSchst in einer Schaltungsbeschreibungs- 

10 sprache und setzt dann den dabei erhaltenen Code in die 

Konf igurationsdaten (in den Kof igurationsdatensatz Oder die 
Konf igurationsdatensatzfblge) urn, unter Verwendung welcher 
der Hardware-Block konf iguriert werden muB, damit dieser der 
durch ihn zu realisierenden Schaltung entspricht. Der Hard- 

15 ware-Block ist dabei vorzugsweise so aufgebaut, dali durch ihn 
je nach Konf iguration verschiedene Schaltungen realisiert 
werden konnen und/oder dafi auch wie vorstehend beschrieben in 
Konf igurationsdaten umgesetzte Befehle in ihm zur Ausftihrung 
gebracht werden konnen, 

20 

Die vorsteheriden Darstellungen und Realisierungsmoglichkeiten 
bezogen sich jeweils auf einen Hardware-Block der in der Fi- 
gur 12 gezeigten Art. Es durfte einleuchten, dali hierauf 
: keine Einschrankung besteht . Die beschriebene Konf igurations- 

25 daten-Generierung lafit sich auch fttr modi fizierte oder er- 
weiterte Hardware-Blocke durchftihiren. Dabei sind sowohl die 
Konf igurationsdaten-Erzeugung als auch die Konf igurierung des 
Hardware-Blocks unter Verwendung dieser Konf igurationsdaten, 
schnell, einfach und effizient durchflihrbar . Nichtsdestotrotz 

30 werden dabei die Komponenten des Hardware-Blocks optimal 

ausgenutzt. Dies alles ermoglicht einen aufierst effizienten 
Betrieb des Hardware-Blocks. 
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Bezugszeichenliste 



1 predecode unit 

2 instruction buffer 

5 3 decode, rename & load unit 

4 s-unit 

5 data cache 

6 memory interface 

10 41 programmable structure buffer 

42 functional unit with programmable structure 

43 integer/address instruction buffer 

44 integer register file 

15 AUx arithmetische Einheit 

CU Vergleichs-Einheit 

DEMUX Demultiplexer 

MUXAx Multiplexer des ersten Typs 

MUXB Multiplexer des zweiten Typs 



20 



WO 00/17771 



PCI7DE99/02878 



52 

Patentahspruche 

1. Verfahren zum Konf igurieren eines konf igurierbaren Hard- 
ware-Blocks / 

5 dad u r. c h g e k e n n z e i c h n e t, • — 
: dafi die Hardware-Block-Konf igurierung unter Verwendung von 
Konfigurationsdaten erfolgt, die aus einer Umsetzung vori 
Befehlen oder Bef ehlsf olgen eines auszuftihrenden Programmes 
resultieren, und dafi bei der Umsetzung der Befehle oder 
10 Bef ehlsf olgen die Schritte 

- Ermittlung der zur Ausftihrung eines jeweiligen Befehls be- 
no tigt en Art von Teileinheit (AUx, CU, DEMUX, MUXAx, MUXB) 
des konf igurierbaren Hardware-Blocks, 

- Auswahl einer noch nicht anderweitig belegten Teileinheit 
15 der zuvor ermittelten Art, und - sofern eine solche Teil- 
einheit gefunden werden konnte - 

- Konf igurieren von um die ausgewahlte Teileinheit herum vor- 
gesehenen konf igurierbaren Verbindungen 

ausgefUhrt werden. 

20 

2. Verfahren nach Anspruch 1, 

d a d u r c h g eke n n z e i c h n e t, 

dafi die Umsetzung mit dem ersten Befehl eines nur einen Ein- 
trittspunkt und einen Austrittspunkt aufweisenden Befehls- 
25 Blocks begonnen wird. 

3. Verfahren nach Anspruch 1 oder 2, 

da dure h gekennzeichnet, 

dafi die Umsetzung nach dem Umsetzen des letzten Befehls eines 
30 nur einen Eintrittspunkt und einen Austrittspunkt aufweisen- 
den Befehls-Blocks automatisch beendet wird. 

4. Verfahren nach Anspruch 2 oder 3, 
dadurch gekennzeichnet, 

35 dafi die Umsetzung hyperblock-weise erfolgt. 
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5. Verfahren nach einem der vorhergehenden Anspriiche, 
dadurch g e k e n n z e i c h n e t , 

dafi die Umsetzung automatisch beendet wird, wenn eine zur Um- 
setzung benotigte Komponente des Hardware-Blocks nicht oder 
5 nicht mehr verfiigbar ist. 

6. Verfahren nach einem der vorhergehenden Anspriiche, 
dadur c h gekennze i c h n e t, 

dafi funktionsmafiig konf igurierbaren Teileinheiten (AUx, CU, 
10 DEMUX, MUXAx, MUXB) des Hardware-Blocks virtuelle Einheiten 
zugeordnet werden, wobei die virtuellen Einheiten Funktionen 
reprasentieren, welche der betreffenden Teileinheit durch 
unterschiedliche Konf igurationen verliehen werden konnen. 

15 7. Verfahren nach Anspruch 6, 

dad u r c h g e k e n n z e i c h n e t, 

dafi die virtuellen Einheiten samtlicher physikalischer Teil- 
einheiten (AUx, CU, DEMUX, MUXAx, MUXB) in einer Tabelle oder 
Liste eingetragen sind. 

20 

8* Verfahren nach Anspruch 7, 

dad u r c h g e k e n n z e i c h n e t, 

dafi die Tabellen- oder Listeneintrage Inf ormationen dartiber 
enthalteri, welcher physikalischen Teileinheit (AUx, CU, 
25 DEMUX, . MUXAx, MUXB) die betreffende virtuelle Einheit zu- 
geordnet ist. 

9. Verfahren nach Anspruch 7 oder 8, 
dadurch gekennze ichnet, 

30 dafi die Tabellen- oder Listeneintrage inf ormationen dartiber 
enthalten, wie die zugeordnete physikalischen Teileinheit 
(AUx, CU, DEMUX, MUXAx, MUXB) zu konf igurieren ist, um ihr 
die durch die virtuelle Einheit reprasentierte Funktion zu 
verleihen. 

35 

10. Verfahren nach einem der vorhergehenden Anspriiche, 
dadurch gekennzeichn e t, 
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dafi die Auswahl einer zur Ausfuhrung eines Befehls benotigten 
Teileinheit (AUx, CU, DEMUX, MUXAx, MUXB) uber eine Suche 
nach einer virtuellen Einheit der benotigten Art erfoigt. 

11. Verf ahren nach Anspruch 10, 

d a d u r c h g e k e n n z e i c h n e t, 
dafi dafiir gesorgt wird, daB die zur Verwendung ausgewahlte 
virtuelle Einheit der benotigten Art und diejenigen virtuel- 
len Einheiten, die der selben physikalischen Teileinheit 
(AUx , CU , DEMUX , MUXAx, MUXB) zugeordnet sind wie die, aus- 
gewahlte virtuelle Einheit, bei nachf olgenden Uiasetzungen 
nicht mehr zur Verwendung ausgewahlt werden konnen, 

12. Verf ahren nach einem der yorhergehenden Anspruche, 
d.adurch gekennzei chnet, 

dafi beim Konf igurieren der um die ausgewahlte Teileinheit 
(AUx, CU, DEMUX, MUXAx, MUXB) herum vorgesehenen konfigurier- 
baren Verbindungen zur Verbindung der betreffenden Teilein- 
heit mit einer durch den umzusetzenden Befehl definierten 
Daten- und/oder Signalquelle tiberprilft wird, ob die betref- 
fende Daten- und/oder Signalquelle ein Speicherbereich ist, 
der zuvor durch eine der Teileinheiten des Hardware-Blocks 
beschrieben wurde. 

13. Verfahren nach Anspruch 12, 

d a d u f c h g e k e n n z e i c h n e t, 

daB dann, wenn festgestellt wird, dafi die durch den umzuset- 
zenden Befehl definierte Daten- und/oder Signalquelle zuvor 
durch eine der Teileinheiten (AUx, CU, DEMUX, MUXAx, MUXB) 
des Hardware-Blocks beschrieben wurde, diese Teileinheit als 
Daten- und/oder Signalquelle verwendet wird. 

14. Verfahren nach einem der vorhergehenden Anspruche, 
dadurch gekennzeichnet, 

dafi beim Konf igurieren der um die ausgewahlte Teileinheit 
(AUx, CU, DEMUX, MUXAx, MUXB) herum vorgesehenen konfigurier- 
baren Verbindungen zur Verbindung der betreffenden Teil- 
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... einheit mit einem durch den urazusetzenden Befehl def inierten 
Daten- und/oder Signalziel tiberpruft wird, ob das betreffende 
Daten- .und/oder Signalziel ein Speicherbereich ist, der a.uch 
durch eine andere Teileinheit des Hardware-Blocks beschrieben 
5 wird. 

15. Verf ahren nach Anspruch 14, 

d a d u r c h g e k e n n z e i c h n e t, 

daB dann, wenn festgestellt wird, dafi das diirch den umzuset- 
10 zenden Befehl def inierte Daten- und/oder Signalziel ein 

Speicherbereich ist, der auch durch eine andere Teileinheit 
(AUx, CU, DEMUX , MUXAx , MUXB) des Hardware-Blocks beschrieben 
wird, ein anderer Speicherbereich als Daten- und/oder Signal- 
ziel verwendet wird. 

15 

16. Verf ahren nach Anspruch 15, 

dad u r c h g e k e n n z e i c h n e t, 

daB fUr die das selbe Daten- und/oder Signalziel reprasentie- 
renden Speicherbereiche das bei superskalaren Prozessoren an- 
20 gewandte register renaming durchgefuhrt wird. 

17. Verf ahren nach einem der vorhergehendeh Anspruche, 
d a d u r c h g e ken n z e i c h n e t, 

daB dann, wenn im umzuset zenden Befehl eine Konstante en thai - 
25 ten ist, nach einem die Konstante enthaltenden Konstanten- 

Speicherbereich gesucht wird und dann, wenn ein solcher Kon- 
stanten-Speicherbereich gefunden wurde, dieser Konstanten- 
Speicherbereich als Daten- und/oder Signalquelle verwendet 
wird. 

30 

18. Verf ahren nach Anspruch 17, 
d a d u r c h g e k e n n z e i c h n e t, 

daB dann, wenn die Konstante nicht bereits in einem der vor- 
handenen Konstanten-Speicherbereiche gespeichert ist, die 
35 Konstante in einen neuen Konstanten-Speicherbereich gespei- 
chert wird, und dieser neue Konstanten-Speicherbereich als 
Daten- und/oder Signalquelle verwendet wird. 
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19. Verfahren insbesondere nach einem der vorhergehenden 
Anspriiche, 

dadurch gekennzeichnet, 
, 5 dafi bei der Umsetzung vori Befehlen in Konf igurationsdaten 
versucht wird, mehrere Hyperblocke Umf assende Pseudo- 
Hyperblocke zu bilden. 

20. Verfahren nach Anspruch 19, 

10 d a d u r c h g e k e n n z e i c h n e t, 

dafi die Pseiido-Hyperblocke unter Verwendung der if-Konversion 
gebildet werden. 

21. Verfahren nach Anspruch 19 oder 20, 

15 dadurch gekennzeichnet, 

dali die Umsetzung von Befehlen in Konf igurationsdaten nach 
Moglichkeit pseudo-hyperblock-weise erfolgt. 

22. Verfahren zum Konf igurieren eines konf igurierbaren Hard- 
20 ware-Blocks, 

dadurch gekennzeichnet, 
dafi die Hardware-Block-Konf igurierung unter Verwendung von 
Konf igurationsdaten erfolgt, die aus einer Umsetzung des 
Codes resultieren, der generiert wird, wenn eine Schaltung, 
25 die durch den konf igurierbaren Hardware-Block realisiert 

werden soil, unter Verwendung einer Schaltungsbeschreibungs- 
sprache definiert wird. 

23. Verfahren nach Anspruch 22, 

30 dadurch gekennzeichnet, 

dafi VHDL als Schaltungsbeschreinbungssprache verwendet wird. 
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(57) Abstract 



The invention relates to various methods for configuring configurable hardware blocks. The methods arc especially characterized by 
generation of the configuration data used to configure the hardware blocks. The methods described for generating configuration data enable 
configuration data to be generated and allow hardware blocks to be configured easily, quickly and efficiently using said configuration data. 



(57) Zusammcnfassung 

Bs werden vcrschiedene Verfahren zur Konrigurierung von konfigurierbaren Hardware-BIdcken beschrieben. Die Vcffahren zcichnen 
sich insbcsondere durch die Generierung der Kohngurationsdateri aus, unter Verwendung weicher die Hardware-BIocke konfiguriert 
werden. Durch die beschricbene Konfigurationsdatcn-Brzeugung kdnncn sowohl die Konfigurationsdaten-Erzeugung selbst als auch die 
Mnrclwarc-Block-Konfigurierung unter Verwendung dieser Konfigurationsdaten eirifach, schnel! und effizient durchgefuhrt werden. 
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